From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Attached partition not considering altered column properties of root partition. |
Date: | 2019-07-30 17:38:19 |
Message-ID: | CA+TgmoZaYJ9DeMiS4fHCU=8YUdvYt5BaAB0qAw6sg+qQBTMLuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 2, 2019 at 9:53 PM Amit Langote <amitlangote09(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-07-30 17:40:06 | Re: TopoSort() fix |
Previous Message | Tom Lane | 2019-07-30 17:36:36 | Re: TopoSort() fix |