public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Dean Rasheed <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: RangeTblEntry.inh vs. RTE_SUBQUERY
Date: Thu, 29 Feb 2024 13:14:51 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CAEZATCXZP9dd4oym=nLzkHswjfBcY6-Xe4RH+v+YLC0jiKR30Q@mail.gmail.com>
<[email protected]>
<[email protected]>
Peter Eisentraut <[email protected]> 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
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: RangeTblEntry.inh vs. RTE_SUBQUERY
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox