Re: BUG #18284: Filter in left lateral join not respected

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

In response to

Responses

Browse pgsql-bugs by date

  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