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

> On 29 Nov 2022, at 17:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> 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 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.

Thanks for confirming.

>> 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.

Oh, ok.  I'll go enforce readonly on all utility statements in HEAD and the
applicable backbranches tonight then.

--
Daniel Gustafsson		https://vmware.com/