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

From Tom Lane
Subject Re: RangeTblEntry.inh vs. RTE_SUBQUERY
Date
Msg-id 2718281.1709230491@sss.pgh.pa.us
Whole thread Raw
In response to Re: RangeTblEntry.inh vs. RTE_SUBQUERY  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: RangeTblEntry.inh vs. RTE_SUBQUERY
Re: RangeTblEntry.inh vs. RTE_SUBQUERY
List pgsql-hackers
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.

I'd be inclined to leave it where it is and just improve the
commentary.  That could read like

 *    inh is true for relation references that should be expanded to include
 *    inheritance children, if the rel has any.  In the parser this
 *    will only be true for RTE_RELATION entries.  The planner also uses
 *    this field to mark RTE_SUBQUERY entries that contain UNION ALL
 *    queries that it has flattened into pulled-up subqueries
 *    (creating a structure much like the effects of inheritance).

If you do insist on moving it, please put it next to relkind so it
packs better.

I agree that perminfoindex seems to have suffered from add-at-the-end
syndrome, and if we do touch the field order you made an improvement
there.  (BTW, who thought they needn't bother with a comment for
perminfoindex?)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Atomic ops for unlogged LSN
Next
From: Jeff Davis
Date:
Subject: Re: Comments on Custom RMGRs