Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.
| От | Andres Freund |
|---|---|
| Тема | Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'. |
| Дата | |
| Msg-id | 20140917215857.GA26236@awork2.anarazel.de обсуждение исходный текст |
| Ответ на | Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'. (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'.
|
| Список | pgsql-bugs |
On 2014-09-17 14:56:42 -0700, Tom Lane wrote: > Michael Paquier <michael.paquier@gmail.com> writes: > > On Sat, Sep 6, 2014 at 1:34 PM, Andres Freund <andres@2ndquadrant.com> wrote: > > Looking at exec_parse_message, empty input string is allowed for a > > cached plan (16503e6f). This solution would break client > > applications/drivers using the extending query protocol and relying on > > this behavior. This EmptyStmt approach sounds like a good option. > > 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? We imo should at least change it in master. Unless I miss something there's really no reason for allowing it. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-bugs по дате отправления: