Re: RangeTblEntry.inh vs. RTE_SUBQUERY - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: RangeTblEntry.inh vs. RTE_SUBQUERY
Date
Msg-id 09a4b507-1c38-4eca-81bb-296245175893@eisentraut.org
Whole thread Raw
In response to Re: RangeTblEntry.inh vs. RTE_SUBQUERY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: RangeTblEntry.inh vs. RTE_SUBQUERY
List 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 by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: POC, WIP: OR-clause support for indexes
Next
From: Alexander Korotkov
Date:
Subject: Re: Table AM Interface Enhancements