Re: Query result differences between PostgreSQL 17 vs 16
От | Richard Guo |
---|---|
Тема | Re: Query result differences between PostgreSQL 17 vs 16 |
Дата | |
Msg-id | CAMbWs48KUM91kYsXP_pETfdFmft8jUNtdjR_3=TGLq+QSZvBfA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Query result differences between PostgreSQL 17 vs 16 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Sat, Mar 1, 2025 at 7:16 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > So in the case at hand, we generate a clone of the "rc3.id IS NOT > NULL" clause that doesn't have a nullingrel bit for the left join to > rc3, but nonetheless is expected to be applied after that join is > performed. There is also a clone that does have a nullingrel bit, but > that doesn't save us in this example because it will only be applied > in join orders other than the one that gets chosen. Exactly! > It'd certainly be nice to make that cleaner, but I'm not sure how, > and we wouldn't risk back-patching the nontrivial changes that would > be needed. So I think rejecting has_clone/is_clone clauses is the > only path forward for now. Yeah, a better fix might be to find a way to perform this NullTest deduction during eval_const_expressions, as you mentioned in the other thread. However, that would also require some nontrivial changes. > Also, I found a test case proving that restriction_is_always_false > needs it too. Thanks. I've included this test case in v3 patch. Thanks Richard
В списке pgsql-bugs по дате отправления: