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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, TAKATSUKA Haruka <harukat@sraoss.co.jp>, pgsql-bugs <pgsql-bugs@postgresql.org>
Date: 2014-09-17T21:56:42Z
Lists: 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