From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers
 assert in PortalRunMulti
In-reply-to: <18984-0f4778a6599ac3ae@postgresql.org>
References: <18984-0f4778a6599ac3ae@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 14 Jul 2025 19:00:02 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <713716.1752520992.1@sss.pgh.pa.us>
Date: Mon, 14 Jul 2025 15:23:12 -0400
Message-ID: <713717.1752520992@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/713717.1752520992%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The following psql script:
> \parse s

> execute s;

> invokes:
> TRAP: failed Assert("qc->commandTag != CMDTAG_UNKNOWN"), File: "pquery.c",
> Line: 1369, PID: 1123863

What this is complaining about, essentially, is that we don't know how
to construct a command tag to send back to the client.  Maybe we could
invent some new command tag out of whole cloth, but I'm inclined to
think it'd be better to forbid empty prepared statements.  Not sure
where that should be enforced, but probably on the server side.

			regards, tom lane