Re: Attached partition not considering altered column properties ofroot partition. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Attached partition not considering altered column properties ofroot partition.
Date
Msg-id CA+TgmoZaYJ9DeMiS4fHCU=8YUdvYt5BaAB0qAw6sg+qQBTMLuQ@mail.gmail.com
Whole thread Raw
In response to Re: Attached partition not considering altered column properties ofroot partition.  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Attached partition not considering altered column properties ofroot partition.  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Tue, Jul 2, 2019 at 9:53 PM Amit Langote <amitlangote09@gmail.com> wrote:
> Thanks for the report.  This seems like a bug.  Documentation claims
> that the child tables inherit column storage options from the parent
> table.  That's actually enforced in only some cases.

I realize I'm just repeating the same argument I've already made
before on other related topics, but I don't think this is a bug.
Inherited-from-parent is not the same as
enforced-to-always-be-the-same-as-parent.  Note that this is allowed,
changing only the child:

rhaas=# create table foo (a int, b text) partition by range (a);
CREATE TABLE
rhaas=# create table foo1 partition of foo for values from (0) to (10);
CREATE TABLE
rhaas=# alter table foo1 alter column b set storage plain;
ALTER TABLE

As is this, changing only the parent:

rhaas=# alter table only foo1 alter column b set storage plain;
ALTER TABLE

How can you possibly argue that the intended behavior is
everything-always-matches when that's not what's documented and
there's absolutely nothing that tries to enforce it?

I'm getting really tired of people thinking that they can invent rules
for table partitioning that were (1) never intended by the original
implementation and (2) not even slightly enforced by the code, and
then decide that those behavior changes should not only be made but
back-patched.  That is just dead wrong.  There is no problem here.
There is no need to change ANYTHING.  There is even less need to do it
in the back branches.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: TopoSort() fix
Next
From: Robert Haas
Date:
Subject: Re: TopoSort() fix