Horton
Menu

Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Michael Paquier <michael@paquier.xyz>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2025-07-15T14:57:54Z
Lists: pgsql-bugs 
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> On 2025-Jul-15, Tom Lane wrote:
>> Yeah, I was starting to think about that solution too.  Removing
>> code seems nicer than adding more.

> Yeah, this makes sense to me too.  I'd rewrite the comment while at it,
> because what's being described as "printing 0 0" no longer occurs in
> this form in this place anymore.  Maybe we could discuss adding
> some commentary to EndCommand where this now happens, but I don't think
> we really need it.

Right, I was giving that comment the side eye too.  I agree that its
second para is no longer useful: the logic it describes certainly
isn't here anymore, and there doesn't seem to be an identifiable place
where we could move it to.  (I think the concern it describes is now
baked into the table design for command tags, specifically that any
given CMDTAG either has or doesn't have a count.)  I might write the
replacement comment more like

     * If query completion data is requested and not yet filled in,
     * and the portal has a default command tag, copy it from there.
     * See QueryRewrite(), step 3, for motivation.

			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 →

  1. Minor cosmetic tweaks

  2. Simplify coding in ProcessQuery

  3. Remove assertion from PortalRunMulti

  4. Represent command completion tags as structs