Re: Attached partition not considering altered column properties of root partition.

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

In response to

Responses

Browse pgsql-hackers by date

  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