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