Adjust things so that the query_string of a cached plan and the sourceText of
commit3b49b7ddba44e2faa17364de3d2a93e22718befe
authortgl <tgl>
Fri, 18 Jul 2008 20:26:06 +0000 (18 20:26 +0000)
committertgl <tgl>
Fri, 18 Jul 2008 20:26:06 +0000 (18 20:26 +0000)
treeaab6a644ecd17d825dcb5d5fe2ef04bc77a0b4c1
parent7d279ea7b5d0943f66c52497abd5db473234569f
Adjust things so that the query_string of a cached plan and the sourceText of
a portal are never NULL, but reliably provide the source text of the query.
It turns out that there was only one place that was really taking a short-cut,
which was the 'EXECUTE' utility statement.  That doesn't seem like a
sufficiently critical performance hotspot to justify not offering a guarantee
of validity of the portal source text.  Fix it to copy the source text over
from the cached plan.  Add Asserts in the places that set up cached plans and
portals to reject null source strings, and simplify a bunch of places that
formerly needed to guard against nulls.

There may be a few places that cons up statements for execution without
having any source text at all; I found one such in ConvertTriggerToFK().
It seems sufficient to inject a phony source string in such a case,
for instance
        ProcessUtility((Node *) atstmt,
                       "(generated ALTER TABLE ADD FOREIGN KEY command)",
                       NULL, false, None_Receiver, NULL);

We should take a second look at the usage of debug_query_string,
particularly the recently added current_query() SQL function.

ITAGAKI Takahiro and Tom Lane
src/backend/commands/portalcmds.c
src/backend/commands/prepare.c
src/backend/commands/trigger.c
src/backend/executor/spi.c
src/backend/parser/analyze.c
src/backend/tcop/postgres.c
src/backend/tcop/utility.c
src/backend/utils/cache/plancache.c
src/backend/utils/mmgr/portalmem.c
src/include/utils/plancache.h
src/include/utils/portal.h