Re: RangeTblEntry.inh vs. RTE_SUBQUERY
От | Peter Eisentraut |
---|---|
Тема | Re: RangeTblEntry.inh vs. RTE_SUBQUERY |
Дата | |
Msg-id | 09a4b507-1c38-4eca-81bb-296245175893@eisentraut.org обсуждение исходный текст |
Ответ на | Re: RangeTblEntry.inh vs. RTE_SUBQUERY (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: RangeTblEntry.inh vs. RTE_SUBQUERY
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: