From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)postgresql(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the |
Date: | 2009-01-07 19:53:54 |
Message-ID: | 200901071953.n07Jrsh12217@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-07 20:20:24 | Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the |
Previous Message | Bruce Momjian | 2009-01-07 19:51:21 | pgsql: Add comment that it is difficult to access the more accurate |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-07 20:20:24 | Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the |
Previous Message | Stephen Frost | 2009-01-07 18:57:17 | Re: Do we still need constraint_exclusion? |