Re: BUG #18261: Inconsistent results of SELECT affected by joined subqueries
От | Alexander Korotkov |
---|---|
Тема | Re: BUG #18261: Inconsistent results of SELECT affected by joined subqueries |
Дата | |
Msg-id | CAPpHfdv-X=XHCqX77OL2RF7YLxtHsXwbKrw1P7-gvRpwb4y=dA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18261: Inconsistent results of SELECT affected by joined subqueries (Richard Guo <guofenglinux@gmail.com>) |
Список | pgsql-bugs |
On Tue, Jan 2, 2024 at 3:43 AM Richard Guo <guofenglinux@gmail.com> wrote: > On Fri, Dec 29, 2023 at 12:32 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Richard Guo <guofenglinux@gmail.com> writes: >> > I've looked into it a bit. The problem lies in how the SJE code handles >> > the transfer of qual clauses from the removed relation to the remaining >> > one. >> >> I am definitely starting to think that the SJE patch was not ready >> for prime time. We keep finding not only minor but major problems >> in it --- I'd call this one a "major" one. Is it time to revert >> and rethink it from scratch? > > I feel the same way. It seems to me that the SJE code still needs some > refactoring to get to a committable state. Thank you for your feedback. Do you have something particular to be done, which requires reverting the feature from the source tree? My concern is that we've already fixed quite a set of bugs after committing to this feature. If we push the feature back into the mailing list thread for possibly a long time, then more conflicting features could be committed (like nullable vars in the past). Thus, we may end up committing it again with a shape not better than it is now. On the other hand, if there is a plan to redesign the feature in a way that greatly reduces the number of potential conflicts, that's another story. ------ Regards, Alexander Korotkov
В списке pgsql-bugs по дате отправления: