| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: struct RelOptInfo member relid comments |
| Date: | 2024-05-24 05:28:53 |
| Message-ID: | 585848.1716528533@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> OJ is an outer join, AFAIU. OJ's have their own relids. If you are
> wondering why not all joins - I think inner joins need not be tracked as
> separated relations in parse tree, but OJ's need to be.
An outer join is necessarily associated with explicit JOIN syntax
in the FROM clause, and each such JOIN has its own rangetable entry
and hence a relid. Inner joins might arise from comma syntax
(that is, "SELECT ... FROM tab1, tab2"). For perhaps-historical
reasons that syntax doesn't give rise to an explicit RTE_JOIN
rangetable entry, so the implied join has no relid.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-05-24 05:33:21 | Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c) |
| Previous Message | Ashutosh Bapat | 2024-05-24 05:23:18 | Re: struct RelOptInfo member relid comments |