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 | 923531.1752595534@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
|
Список | pgsql-bugs |
I wrote: > BTW, with Asserts disabled it works fine: > ... > (I did not look into how come that works... the correct > command tag must be getting filled in later, but where?) I traced through this, and the answer is that there are two levels of Portal, an outer one that holds the EXECUTE command (and has portal->qc.commandTag = CMDTAG_EXECUTE) and an inner one that runs the prepared statement's list (and has portal->qc.commandTag = CMDTAG_UNKNOWN, because that list is empty). But ExecuteQuery passes down the outer "qc" parameter to the inner recursion level. So without the Assert, the inner invocation of PortalRunMulti leaves qc->commandTag = CMDTAG_UNKNOWN, and then the very same stanza of PortalRunMulti replaces that with CMDTAG_EXECUTE in the outer recursion level. So it's just wrong for PortalRunMulti to assert that the computation of qc->commandTag is necessarily complete. If we wanted to replace that, it might be appropriate to have an assertion at the top level (exec_simple_query) but I'm not very sure what that would buy us. It'll be apparent enough what happened from the reported "???" command tag, and the top-level assertion would contribute exactly nada to identifying where we'd missed setting it. In short, Alvaro's patch definitely seems like the right one, modulo quibbles about rewriting the comment. Perhaps we should add something about the possibility that an outer Portal level can supply a default command tag if we lack one now? regards, tom lane
В списке pgsql-bugs по дате отправления: