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 | 5427.1410991002@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'. (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: BUG #11335: an invalid prepare statement causes crash at
log_statement = 'mod' or 'ddl'.
Re: BUG #11335: an invalid prepare statement causes crash at log_statement = 'mod' or 'ddl'. |
Список | pgsql-bugs |
Michael Paquier <michael.paquier@gmail.com> writes: > On Sat, Sep 6, 2014 at 1:34 PM, Andres Freund <andres@2ndquadrant.com> wrote: >> On 2014-09-06 16:25:28 -0400, Tom Lane wrote: >>> I don't think this fix is either appropriate or adequate. >> Agreed (and commented offlist. Which probably was a mistake). > This has not been reverted yet. Wouldn't it be better to do that asap? Probably not until someone codes a better fix. I have it on my plate to look into a better fix, but I've been horribly busy lately. > 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. The realistic alternatives are either to fix the code to support having plansource->raw_parse_tree be NULL, or to invent a dummy node type to put there. Not sure which is better. regards, tom lane
В списке pgsql-bugs по дате отправления: