Yep, I couldn't find a better way to do it when I added debug_query_string long ago. Unless we go to a lot of work to parse the string, we could end up with something worse than we have now.
--------------------------------------------------------------------------- Neil Conway wrote: > 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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster