Achilleas Mantzios <achill@xxxxxxxxxxxxxxxxxxxxx> writes:
> dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = currval(('public.itemshist_pkid_seq'::text)::regclass);
currval() is marked volatile, so that's not a legal index
qualification.
(Perhaps there's an argument that it'd be more useful to consider it
stable, but certainly if you used it in the same query as a nextval()
on the same sequence, you'd have trouble.)
> -- but if I compare against select currval it uses the index:
> dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = ( SELECT currval(('public.itemshist_pkid_seq'::text)::regclass));
Yeah, the planner does not consider uncorrelated scalar sub-selects
to be volatile; they'll be evaluated only once per query, regardless
of what they contain. So this is sort of a traditional hack for
freezing a volatile function's result. (I have no idea whether other
RDBMSes read the SQL spec the same way on this point.)
regards, tom lane
