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

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