Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> On Tue, Jul 3, 2018 at 3:20 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.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.
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. Be careful that
you don't end up with zero privilege checks on the partition root :-(
regards, tom lane