From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: xinwen@stu.scu.edu.cn, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17702: An assert failed in parse_utilcmd.c
In-reply-to: <ED7A6ED5-20D5-43E8-B75C-13B155ADFA30@yesql.se>
References: <17702-ad24fdcdd1e9047a@postgresql.org>
 <ED7A6ED5-20D5-43E8-B75C-13B155ADFA30@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Tue, 29 Nov 2022 12:31:08 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <968495.1669738953.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Nov 2022 11:22:33 -0500
Message-ID: <968496.1669738953@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/968496.1669738953%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
>> On 29 Nov 2022, at 03:45, PG Bug reporting form <noreply@postgresql.org=
> wrote:
>> When executing the following query:
>> =

>> CREATE FUNCTION function0 () RETURNS INT LANGUAGE SQL AS $$ CREATE TABL=
E
>> table1 ( column0 INT CHECK ( 'x' =3D 'x' )) ; SELECT 1 ; $$ ;
>> SELECT function0 () FROM ( VALUES ( 1 ) , ( 1 ) ) AS alias0;
>> =

>> I get a failed assertion with the following stacktrace:

> This is AFAICT due to the utility statement already having gone through =
parse
> analysis and thus have the constraints list already set here.  Forcing a=
 read-
> only protection via the functionality from 7c337b6b5 the assertion is av=
oided
> and the function executes as expected:

Right.

> Maintaining a list of statements that scribble and force those to readon=
ly
> could be a way forward?  Forcing processing of all utility statements to=
 be
> readonly seems like a blunt instrument here, not sure what the best cour=
se of
> action would be.

No, I think that's exactly what we should do.  This is just a silly
oversight in 7c337b6b5 --- I should have thought about SQL functions
executing more than once in a query.

(Eventually we ought to nuke functions.c's private version of a plan
cache in favor of using plancache.c, but nobody's got to that yet.
It'd be more obvious then that we have to protect the cached copy.)

			regards, tom lane