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

On Wed, Jul 31, 2019 at 2:38 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> 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?

You're right. The patch as proposed is barely enough to ensure the
everything-always-matches behavior. Let's update^H^H^H^H^H^H^H forget
about the patch. :)

I do remember that we made a list of things that we decided must match
in all partitions, which ended up being slightly bigger than the same
list for regular inheritance children, but much smaller than the list
of all the things that could be different among children. I forgot we
did that when replying to Prabhat's report. In this particular case,
I do have doubts about whether we really need attstorage to be the
same in all the children, so maybe I should've first asked why we
should think of this as a bug.

> 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.

OK, I'm withdrawing my patch.

Thanks,
Amit