While reviewing Joachim Wieland's patch to add a pg_cursors system view,
I noticed that the patch assumes that debug_query_string contains the
portion of the submitted query string that corresponds to the SQL
statement we are currently executing. That is incorrect:
debug_query_string contains the *entire* verbatim query string sent by
the client. So if the client submits the query string "SELECT 1; SELECT
2;", debug_query_string will contain exactly that string. (psql actually
splits queries like the above into two separate FE/BE messages -- to see
what I'm referring to, use libpq directly, or start up a copy of the
standalone backend.)
This makes debug_query_string the wrong thing to use for the pg_cursors
and pg_prepared_statements views, but it affects other parts of the
system as well: for example, given PQexec(conn, "SELECT 1; SELECT 2/0;")
and log_min_error_statement = 'error', the postmaster will log:
ERROR: division by zero
STATEMENT: SELECT 1; SELECT 2/0;
which seems misleading, and is inconsistent with the documentation's
description of this configuration parameter. Admittedly this isn't an
enormous problem, but I think the current behavior isn't ideal.
Unfortunately I don't see an easy way to fix this. It might be possible
to extra a semicolon separated list of query strings from the parser or
lexer, but that would likely have the effect of munging comments and
whitespace from the literal string submitted by the client, which seems
the wrong thing to do for logging purposes. An alternative might be to
do a preliminary scan to look for semicolon delimited query strings, and
then pass each of those strings into the raw_parser() separately, but
that seems quite a lot of work (and perhaps a significant runtime cost)
to fix what is at worst a minor UI wrinkle.
Thoughts?
-Neil
