On 03.03.24 11:02, Peter Eisentraut wrote:
> On 29.02.24 19:14, Tom Lane wrote:
>> Peter Eisentraut <peter@eisentraut.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.
I have committed the patches for this discussion.
Related discussion will continue at
https://www.postgresql.org/message-id/flat/4b27fc50-8cd6-46f5-ab20-88dbaadca645@eisentraut.org
/ https://commitfest.postgresql.org/47/4697/ .