> From: Robert Haas [mailto:robertmh...@gmail.com] > On Mon, Dec 8, 2014 at 2:56 PM, Andres Freund > <and...@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 partition that is further sub-partitioned? We might allocate storage for a partition at some point and then later choose to sub-partition it. In such a case, perhaps, we would have to move existing data to the storage of subpartitions and deallocate the partition's storage. In other words only leaf relations in a partition hierarchy would have storage. Is there such a notion within code for some other purpose or we'd have to invent it for partitioning scheme? Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
