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