From: Tom Lane <tgl@sss.pgh.pa.us>
To: Achilleas Mantzios <achill@matrix.gatewaynet.com>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: Index ignored on pkid = curval('some_seq'),
 used with pkid = (select curval(''some_seq') )
In-reply-to: <0ee1a3a2-7394-d518-2e22-790a84ef558c@matrix.gatewaynet.com>
References: <0ee1a3a2-7394-d518-2e22-790a84ef558c@matrix.gatewaynet.com>
Comments: In-reply-to Achilleas Mantzios <achill@matrix.gatewaynet.com>
	message dated "Wed, 27 Feb 2019 10:54:11 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14553.1551280909.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Feb 2019 10:21:49 -0500
Message-ID: <14554.1551280909@sss.pgh.pa.us>
Precedence: bulk

Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
> dynacom=3D# explain analyze update itemshist set reason=3D'{foo,bar}' wh=
ere pkid =3D 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=3D# explain analyze update itemshist set reason=3D'{foo,bar}' wh=
ere pkid =3D ( SELECT currval(('public.itemshist_pkid_seq'::text)::regclas=
s));

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