From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Analyzing bug 8049 |
Date: | 2013-04-12 14:58:13 |
Message-ID: | 17439.1365778693@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Apr 11, 2013 at 1:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The plan I'm considering is to get this written and committed to HEAD
>> in the next week, so that it can go out in 9.3beta1. After the patch
>> has survived a reasonable amount of beta testing, I'd be more comfortable
>> about back-patching into 9.2.
> I'm not very sanguine about the chances that back-patching this won't
> provoke any screams of agony ... but I don't have a better idea,
> either. Letting queries return wrong answers isn't a superior
> solution, for sure.
The only alternative I can see is to make a back-patch that just teaches
get_eclass_for_sort_expr() to compute valid nullable_relids for the sort
expression. That's necessary code in any case, and it would fix the
immediately complained-of bug. The thing that scares me is that it is
now clear that equivclass.c is capable of considering two expressions to
be equivalent when they should not be; that is, I'm afraid there are
variants of the problem that would not be cured by such a limited
back-patch. But maybe I should try to create such an example before
proposing the more invasive approach.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-04-12 15:13:59 | Re: [PATCH] pg_regress and non-default unix socket path |
Previous Message | Scott Marlowe | 2013-04-12 14:48:30 | Re: after 9.2.4 patch vacuumdb -avz not analyzing all tables |