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