From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: SQLFunctionCache and generic plans
In-reply-to: <8216639.NyiUUSuA9g@aivenlaptop>
References: <8216639.NyiUUSuA9g@aivenlaptop>
Comments: In-reply-to Ronan Dunklau <ronan.dunklau@aiven.io>
	message dated "Tue, 07 Feb 2023 15:55:34 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3084884.1675783797.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 07 Feb 2023 10:29:57 -0500
Message-ID: <3084885.1675783797@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3084885.1675783797%40sss.pgh.pa.us>
Precedence: bulk

Ronan Dunklau <ronan.dunklau@aiven.io> writes:
> The following comment can be found in functions.c, about the SQLFunction=
Cache:

>  * Note that currently this has only the lifespan of the calling query.
>  * Someday we should rewrite this code to use plancache.c to save parse/=
plan
>  * results for longer than that.

> I would be interested in working on this, primarily to avoid this proble=
m of =

> having generic query plans for SQL functions but maybe having a longer l=
ived =

> cache as well would be nice to have.
> Is there any reason not too, or pitfalls we would like to avoid ?

AFAIR it's just lack of round tuits.  There would probably be some
semantic side-effects, though if you pay attention you could likely
make things better while you are at it.  The existing behavior of
parsing and planning all the statements at once is not very desirable
--- for instance, it doesn't work to do
	CREATE TABLE foo AS ...;
	SELECT * FROM foo;
I think if we're going to nuke this code and start over, we should
try to make that sort of case work.

			regards, tom lane