Neil Conway wrote:
> On Mon, 2007-07-05 at 19:48 +0100, Tomas Doran wrote:
> > As suggested in the TODO list (and as I need the functionality
> > myself), I have implemented the current_query interface to
> > debug_query_string.
It actually has been removed from the TODO list since you saw it last.
> Comments:
>
...
> * AFAIK debug_query_string() still does the wrong thing when the user
> submits multiple queries in a single protocol message (separated by
> semi-colons). Not sure there's a way to fix that that is both easy and
> efficient, though...
The problem with the last bullet is pretty serious. It can be
illustrated with psql:
$ psql -c 'set log_statement="all";select 1;select 2;' test
Server log shows:
STATEMENT: set log_statement=all;select 1;select 2;
Obviously this is what current_query() would return if we commit this
patch, and it probably isn't 100% accurate. I see dblink exposes this:
http://www.postgresql.org/docs/8.3/static/contrib-dblink-current-query.html
Returns the currently executing interactive command string of the local database session, or NULL if it can't be
determined. Note that this function is not really related to <filename>dblink</>'s other functionality. It is
providedsince it is sometimes useful in generating queries to be forwarded to remote databases.
but making it more widely available with a possible inaccurate result is
a problem. We can't think of anyway to fix this cleanly --- it would
require a separate parser pass to split queries by semicolons (which
psql does by default in interactive mode). Right now the parser does
the splitting as part of its normal single-parse operation and just
creates parse trees that don't have string representations.
Perhaps we could name it received_query() to indicate it is what the
backend received and it not necessarily the _current_ query.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +