Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.
Дата
Msg-id 5537.1410999052@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.  (Tatsuo Ishii <ishii@postgresql.org>)
Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-bugs
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-09-17 14:56:42 -0700, Tom Lane wrote:
>> Yeah, on second thought I have doubts about the throw-error approach too.
>> We've allowed this historically for a very long time, so I'm afraid we'd
>> get a lot of pushback if we change the external behavior now.

> I have a hard time believing this. Are we really believing that there's
> a significant number of clients preparing whitespace?

I don't know about "significant number", but the case is specifically
called out as legal in the FE/BE protocol spec, for example here:

   Therefore, an Execute phase is always terminated by the appearance of
   exactly one of these messages: CommandComplete, EmptyQueryResponse
   (if the portal was created from an empty query string), ErrorResponse,
   or PortalSuspended.

If we change it, that's a protocol break, and I don't think that being a
tad cleaner is sufficient argument for that.

            regards, tom lane

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

Предыдущее
От: Elvis Pranskevichus
Дата:
Сообщение: Re: Assertion failure in get_appendrel_parampathinfo
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.