Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Sep 4, 2013 at 9:26 PM, Bruce Momjian <br...@momjian.us> wrote:
>> I have not heard any feedback on this patch, so I would like to apply it
>> to give us a nested ROW/IS NULL API we can document. It would have to
>> be marked in the release notes as a backward incompatibility.
> I don't have time to look at this in detail right now, but I think
> that's considerably premature. I'm not convinced that we understand
> all of the problems in this area are yet, let alone the solutions.
> And I notice that you haven't substantively responded to some of Tom's
> concerns.
In particular, I don't think it's a good idea to change
eval_const_expression's behavior in an incompatible way that simply
makes it differently inconsistent with other IS NULL code paths.
We should leave things alone until we have a full fix, otherwise we'll
just be breaking people's apps repeatedly.
I would also say that allowing eval_const_expression to drive what we
think the "right" behavior is is completely backwards, because it's
about the least performance-critical case. You should be looking at
execQual.c first.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
