Re: Analyzing bug 8049
От | Tom Lane |
---|---|
Тема | Re: Analyzing bug 8049 |
Дата | |
Msg-id | 17439.1365778693@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Analyzing bug 8049 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Analyzing bug 8049
Re: Analyzing bug 8049 |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Apr 11, 2013 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: