From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RangeTblEntry.inh vs. RTE_SUBQUERY |
Date: | 2024-03-03 10:02:48 |
Message-ID: | 09a4b507-1c38-4eca-81bb-296245175893@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29.02.24 19:14, Tom Lane wrote:
> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
>> In nodes/parsenodes.h, it says both
>> This *must* be false for RTEs other than RTE_RELATION entries.
>
> Well, that's true in the parser ...
>
>> and also puts it under
>> Fields valid in all RTEs:
>> which are both wrong on opposite ends of the spectrum.
>> I think it would make more sense to group inh under "Fields valid for a
>> plain relation RTE" and then explain the exception for subqueries, like
>> it is done for several other fields.
>
> Dunno. The adjacent "lateral" field is also used for only selected
> RTE kinds.
The section is
/*
* Fields valid in all RTEs:
*/
Alias *alias; /* user-written alias clause, if any */
Alias *eref; /* expanded reference names */
bool lateral; /* subquery, function, or values is
LATERAL? */
bool inh; /* inheritance requested? */
bool inFromCl; /* present in FROM clause? */
List *securityQuals; /* security barrier quals to apply, if
any */
According to my testing, lateral is used for RTE_RELATION, RTE_SUBQUERY,
RTE_FUNCTION, RTE_TABLEFUNC, RTE_VALUES, which is 5 out of 9 possible.
So I think it might be okay to relabel that section (in actuality or
mentally) as "valid in several/many/most RTEs".
But I'm not sure what reason there would be for having inh there, which
is better described as "valid for RTE_RELATION, but also borrowed by
RTE_SUBQUERY", which is pretty much exactly what is the case for relid,
relkind, etc.
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-03-03 11:48:07 | Re: Table AM Interface Enhancements |
Previous Message | Alena Rybakina | 2024-03-03 09:48:19 | Re: POC, WIP: OR-clause support for indexes |