On 27/2/19 5:21 μ.μ., Tom Lane wrote:
> Achilleas Mantzios <achill@matrix.gatewaynet.com> 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.)
Thanks Tom.
>
> regards, tom lane
>
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt