Tom Lane wrote:
> Log Message:
> -----------
> 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.
I looked at the use of 'debug_query_string'; I didn't see how
current_query() could access the more concise query string that is
stored in various structures (comment added); it works now by accessing
the global variable 'debug_query_string'.
I think we should keep the use of 'debug_query_string' as output in the
server logs unchanged because we need all the queries printed in the
logs in one line.
I did update the comment next to debug_query_string to mention it is the
_client_ query string; I am afraid renaming it to 'client_query_string'
would break 3rd party apps.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
