> From: Robert Haas [mailto:robertmhaas@gmail.com]
> On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund
> <andres@2ndquadrant.com> wrote:
> >> I don't think that's mutually exclusive with the idea of
> >> partitions-as-tables. I mean, you can add code to the ALTER TABLE
> >> path that says if (i_am_not_the_partitioning_root) ereport(ERROR, ...)
> >> wherever you want.
> >
> > That'll be a lot of places you'll need to touch. More fundamentally: Why
> > should we name something a table that's not one?
>
> Well, I'm not convinced that it isn't one. And adding a new relkind
> will involve a bunch of code churn, too. But I don't much care to
> pre-litigate this: when someone has got a patch, we can either agree
> that the approach is OK or argue that it is problematic because X. I
> think we need to hammer down the design in broad strokes first, and
> I'm not sure we're totally there yet.
>
In heap_create(), do we create storage for a top level partitioned table (say, RELKIND_PARTITIONED_TABLE)? How about a
partitionthat is further sub-partitioned? We might allocate storage for a partition at some point and then later choose
tosub-partition it. In such a case, perhaps, we would have to move existing data to the storage of subpartitions and
deallocatethe partition's storage. In other words only leaf relations in a partition hierarchy would have storage. Is
theresuch a notion within code for some other purpose or we'd have to invent it for partitioning scheme?
Thanks,
Amit
