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

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

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/