Re: defer statement logging until after parse

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: defer statement logging until after parse
Дата
Msg-id 9621.1079106679@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: defer statement logging until after parse  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: defer statement logging until after parse  (Andrew Dunstan <andrew@dunslane.net>)
Re: defer statement logging until after parse  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-patches
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Has any of this discussion taken into account the fact that a
>> querystring may contain multiple commands?

> What does the parser do if one of the statements has an error and the
> others are OK?

The whole thing is rejected.  This is just an instance of the general
rule that processing of the entire querystring is abandoned at the first
error.

The current definition of log_statement has no problem because we print
the whole string, once, before parsing starts.  If you put a printout
into the per-parse-tree loop then I think you are going to get multiple
printouts of the same string.  You could add some state to prevent more
than one printout per querystring, but even then you'll get complaints
"I asked for DDL only, why did it print this SELECT?".  ISTM the only
way to make it "work" without obvious implementation artifacts is to
actually break down the string into individual commands, which is more
work than I think this feature is worth.

            regards, tom lane

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: defer statement logging until after parse
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: defer statement logging until after parse