Re: BUG #17702: An assert failed in parse_utilcmd.c

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 29 Nov 2022, at 03:45, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
>> When executing the following query:
>>
>> CREATE FUNCTION function0 () RETURNS INT LANGUAGE SQL AS $$ CREATE TABLE
>> table1 ( column0 INT CHECK ( 'x' = '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 avoided
> and the function executes as expected:

Right.

> Maintaining a list of statements that scribble and force those to readonly
> 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 course 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