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" <[EMAIL PROTECTED]> 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 > ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org