From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | holger(dot)reise(at)vitagroup(dot)ag |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18284: Filter in left lateral join not respected |
Date: | 2024-01-11 16:01:39 |
Message-ID: | 74950.1704988899@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> The following script returns two rows with `666`, whereas `null` is to be
> expected:
> WITH r1 AS (VALUES(null)),
> r2 AS (VALUES(null), (null))
> SELECT ljl.val_filtered
> FROM r1
> LEFT JOIN(
> SELECT j666.val FROM r2
> JOIN (SELECT 666 AS val) as j666 ON true
> )AS lj_r2 ON true
> LEFT JOIN LATERAL(
> SELECT lj_r2.val AS val_filtered
> WHERE false
> ) AS ljl ON true;
Hmph ... this has been broken for a good long while. Bisecting
shows it gave the right answer before
4be058fe9ec5e630239b656af21fc083371f30ed is the first bad commit
commit 4be058fe9ec5e630239b656af21fc083371f30ed
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Mon Jan 28 17:54:10 2019 -0500
In the planner, replace an empty FROM clause with a dummy RTE.
so I'm betting that missed a condition about when it is safe to
flatten RTE_RESULT RTEs. Will look, thanks for the report!
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-01-11 17:30:39 | Re: BUG #18284: Filter in left lateral join not respected |
Previous Message | Robert Haas | 2024-01-11 14:34:56 | Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger |