Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2025-07-14T19:23:12Z
Lists: pgsql-bugs
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Minor cosmetic tweaks
- e76221bd95f0 19 (unreleased) landed
-
Simplify coding in ProcessQuery
- a27c40bfe8ab 19 (unreleased) landed
-
Remove assertion from PortalRunMulti
- e0d3f3cfb6f2 18.0 landed
- c2720ac6010a 15.14 landed
- b9a89682846f 14.19 landed
- b8926a5b4bb8 19 (unreleased) landed
- 4871c1e9cb6e 16.10 landed
- 43cd85962755 13.22 landed
- 0c466f5e0b34 17.6 landed
-
Represent command completion tags as structs
- 2f9661311b83 13.0 cited