Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Date
Msg-id 743115.1752529222@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti  (Aleksander Alekseev <aleksander@tigerdata.com>)
Responses Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
List pgsql-bugs
Aleksander Alekseev <aleksander@tigerdata.com> writes:
>> That being the case, maybe we should band-aid this by returning
>> EXECUTE if the prepared statement is empty.

> This sounds pretty straightforward and seems to solve the problem.
> Patch attached.

Hmm, throwing an error is exactly not what I was suggesting above.
The attached quick draft (needs attention to comments) results in

regression=# \parse s

regression=# execute s;
EXECUTE

which matches the behavior of pre-v12 servers.

(BTW, I wonder why psql is emitting an extra newline after \parse.)

            regards, tom lane

diff --git a/src/backend/tcop/pquery.c b/src/backend/tcop/pquery.c
index d1593f38b35..2d998e87846 100644
--- a/src/backend/tcop/pquery.c
+++ b/src/backend/tcop/pquery.c
@@ -1365,8 +1365,8 @@ PortalRunMulti(Portal portal,
     {
         if (portal->qc.commandTag != CMDTAG_UNKNOWN)
             CopyQueryCompletion(qc, &portal->qc);
-        /* If the caller supplied a qc, we should have set it by now. */
-        Assert(qc->commandTag != CMDTAG_UNKNOWN);
+        else
+            qc->commandTag = CMDTAG_EXECUTE;
     }
 }


pgsql-bugs by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Next
From: Tom Lane
Date:
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti