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