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

> 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:
> 
> Core was generated by `postgres: postgres test [local] SELECT               
> '.
> Program terminated with signal SIGABRT, Aborted.
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007faf78ccc859 in __GI_abort () at abort.c:79
> #2  0x000055af27392a88 in ExceptionalCondition
> (conditionName=conditionName@entry=0x55af274b0131 "stmt->constraints ==
> NIL", errorType=errorType@entry=0x55af273f0498 "FailedAssertion",    
> fileName=fileName@entry=0x55af274ae8f8

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:

diff --git a/src/backend/executor/functions.c b/src/backend/executor/functions.c
index e134a82ff7..b0941151b2 100644
--- a/src/backend/executor/functions.c
+++ b/src/backend/executor/functions.c
@@ -884,7 +884,7 @@ postquel_getnext(execution_state *es, SQLFunctionCachePtr fcache)
        {
                ProcessUtility(es->qd->plannedstmt,
                                           fcache->src,
-                                          false,
+                                          (nodeTag(es->qd->plannedstmt->utilityStmt) == T_CreateStmt ? true : false),
                                           PROCESS_UTILITY_QUERY,
                                           es->qd->params,
                                           es->qd->queryEnv,

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.

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