Re: debug_query_string and multiple statements

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: debug_query_string and multiple statements
Дата
Msg-id 200601181745.k0IHjT411747@candle.pha.pa.us
обсуждение исходный текст
Ответ на debug_query_string and multiple statements  (Neil Conway <neilc@samurai.com>)
Список pgsql-hackers
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,
Pennsylvania19073
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: Unique constraints for non-btree indexes
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Surrogate keys (Was: enums)