On Wed, Oct 18, 2017 at 4:53 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > My view is that the fact that partitioning uses inheritance is just an > implementation detail. We shouldn't let historical behavior for > inheritance dictate behavior for partitioning. Inheritance has many > undesirable warts.
I am OK with filing down warts over time, but to be clear, I think it's too late to change things like this in v10, which has shipped. >> > The alter table docs say that ONLY must be specified if one does not >> > want to modify descendants, so I think this is a bug. >> >> Just to clarify, if we do think of it as a bug, then it will apply to the >> inheritance case as well, right? > > I'd leave it alone. I don't think it's a good idea for table partitioning and table inheritance to behave differently. Generally, I think we don't want to end up with three categories of behavior: commands that recurse always, commands that recurse to partitions but not inheritance children, and commands that don't recurse. If we now think that ALTER TABLE .. OWNER TO should recurse, then we should change that to do so in all cases and document it as a backward incompatibility. I think this issue has very little to do with table partitioning per se. As Amit says, this is a longstanding behavior and it would have been far stranger than where we are if the commit to implement table partitioning had changed it. I suggest starting new threads for changes you want to make instead of tacking them all onto this one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
