If we want to save the SQL statement for some database objects(table, view,
etc.),
the backend will see the same problem. Here is an example. create table s(sno int, sname char(10)); select 1;
I recall that some DBMS will store the statement for table s like this: create table s(sno int, sname char(10));
We should also treat the comments.
"Neil Conway" <neilc@samurai.com> wrote message
> 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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>