Re: pgsql: Clarify use of temporary tables within partition trees

On 2018/07/04 1:21, Tom Lane wrote:
> Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
>> On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote
>> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>> Maybe because that's what's done for the root parent in a plain
>>> inheritance hierarchy, which is always a plain table. In that case, one
>>> RTE is for its role as the parent (with rte->inh = true) and another is
>>> for its role as a child (with rte->inh = false). The former is processed
>>> as an append rel and the latter as a plain rel that will get assigned scan
>>> paths such as SeqScan, etc.
>
>> Yes that's true.
>
> Yes, that's exactly why there are two RTEs for the parent table in normal
> inheritance cases. I concur with the idea that it shouldn't be necessary
> to create a child RTE for a partitioning parent table --- we should really
> only need the appendrel RTE plus RTEs for tables that will be scanned.
>
> However, it's not clear to me that this is a trivial change for multilevel
> partitioning cases. Do we need RTEs for the intermediate nonleaf levels?
> In the abstract, the planner and executor might not need them. But the
> code that deals with partitioning constraint management might expect them
> to exist.

We do need RTEs for *all* parents (non-leaf tables) in a partition tree,
each of which we need to process as an append rel (partition pruning is
invoked separately for each non-leaf table). What we *don't* need for
each of them is the duplicate RTE with inh = false, because we don't need
to process them as plain rels.

> Another point is that executor-start-time privilege checking is driven
> off the RTE list, so we need an RTE for any table that requires priv
> checks, so we might need RTEs for intermediate levels just for that.
>
> Also, IIRC, the planner sets up the near-duplicate RTEs for inheritance
> cases so that only one of them is privilege-checked.

Yeah, I see in prepunion.c that the child RTE's requiredPerms is set to 0,
with the following comment justifying it:

"Also, set requiredPerms to zero since all required permissions checks are
done on the original RTE."

> Be careful that
> you don't end up with zero privilege checks on the partition root :-(

The original RTE belongs to the partition root and it's already in the
range table, so its privileges *are* checked.

Thanks,
Amit