Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
От | Tom Lane |
---|---|
Тема | Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti |
Дата | |
Msg-id | 905237.1752591474@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
|
Список | 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
В списке pgsql-bugs по дате отправления: