On Tue, Oct 9, 2018 at 11:07 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Langote <langote_amit...@lab.ntt.co.jp> writes: > > On 2018/10/08 3:55, Tom Lane wrote: > >> I didn't like the idea of unifying ModifyTable.nominalRelation with > >> the partition root info. Those fields serve different masters --- > >> nominalRelation, at least in its original intent, is only meant for > >> use of EXPLAIN and might have nothing to do with what happens at > >> execution. So even though unifying them would work today, we might > >> regret it down the line. Instead I left that field alone and added > >> a separate rootRelation field to carry the partition root RT index, > >> which ends up being the same number of fields anyway since we don't > >> need a flag for is-the-nominal-relation-a-partition-root. > > > Thanks for pushing that. I'd also named it 'rootRelation' in my original > > patch before David had objected to calling it that, because a command may > > not specify the "actual" root of a partition tree; it could be a non-root > > partitioned table. He'd suggested 'partitionedTarget' for the new field > > [1], stressing the "target" part. Maybe, 'rootRelation' isn't too > > confusing though. > > Well, it's the root so far as the current query is concerned --- we do not > take any semantic account of partitioning levels that might exist above > the table named in the query, do we?
We don't, and I personally agree with the reasoning behind calling it rootRelation. Thanks, Amit