On Mon, Sep 15, 2025 at 3:43 PM Tom Lane <[email protected]> wrote: > anything to the RTE's eref. While that makes your argument > nominally true, I'd be inclined to argue that this was an oversight > and it should have changed the alias/eref fields to look like other > RTE_RESULTs. (I've not investigated, but I wonder what your > patch prints for such cases.)
It just prints "-> Result" and that's it, as in this example:
robert.haas=# create or replace function absolutely_not() returns bool
return false;
CREATE FUNCTION
robert.haas=# explain (costs off) select * from generate_series(1,3) g
full join absolutely_not() n on true;
QUERY PLAN
------------------------------------------
Merge Full Join
-> Function Scan on generate_series g
-> Materialize
-> Result
(4 rows)
robert.haas=# explain (costs off, range_table) select * from
generate_series(1,3) g full join absolutely_not() n on true;
QUERY PLAN
------------------------------------------
Merge Full Join
-> Function Scan on generate_series g
Scan RTI: 1
-> Materialize
-> Result
RTIs: 2
RTI 1 (function, in-from-clause):
Alias: g ()
Eref: g (g)
WITH ORDINALITY: false
RTI 2 (result, in-from-clause):
Alias: n ()
Eref: n (n)
RTI 3 (join, in-from-clause):
Eref: unnamed_join (g, n)
Join Type: Full
(16 rows)
Here's a new patch set. My main questions are:
1. Did I miss anything you wanted fixed in 0001?
2. Should 0001 be combined with 0002 or kept separate?
3. Do you have a preference between this version of 0003 and the older
revision that just ignored outer-join relids?
--
Robert Haas
EDB: http://www.enterprisedb.com
v6-0002-Consider-a-Result-node-s-relids-in-ExplainPreScan.patch
Description: Binary data
v6-0001-Keep-track-of-what-RTIs-a-Result-node-is-scanning.patch
Description: Binary data
v6-0003-Ensure-that-all-joinrel-RTIs-are-discoverable-fro.patch
Description: Binary data
