On Wed, Oct 18, 2017 at 4:53 AM, Alvaro Herrera <alvherre@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
