Re: debug_query_string and multiple statements

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(at)samurai(dot)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
>