From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, Ronald Cruz <cruz(at)rentec(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Ford <pford(at)rentec(dot)com>, "Aaron J(dot) Garcia" <agarcia(at)rentec(dot)com> |
Subject: | Re: Query result differences between PostgreSQL 17 vs 16 |
Date: | 2025-03-03 06:50:38 |
Message-ID: | CAMbWs48KUM91kYsXP_pETfdFmft8jUNtdjR_3=TGLq+QSZvBfA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Mar 1, 2025 at 7:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-03-03 08:00:42 | Re: BUG #18828: Crash when pg_get_logical_snapshot_meta() passed empty string |
Previous Message | Richard Guo | 2025-03-03 06:40:47 | Re: Query result differences between PostgreSQL 17 vs 16 |