On Wed, Nov 12, 2014 at 5:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I thought putting the partition boundaries into pg_inherits was a >> strange choice. I'd put it in pg_class, or in pg_partition if we >> decide to create that. > > Yeah. I rather doubt that we want this mechanism to be very closely > tied to the existing inheritance features. If we do that, we are > going to need a boatload of error checks to prevent people from breaking > partitioned tables by applying the sort of twiddling that inheritance > allows.
Well, as I said upthread, I think it would be a pretty poor idea to imagine that the first version of this feature is going to obsolete everything we've done with inheritance. Are we going to reinvent the machinery to make inheritance children get scanned when the parent does? Reinvent Merge Append? >> Maybe as anyarray, but I think pg_node_tree >> might even be better. That can also represent data of some arbitrary >> type, but it doesn't enforce that everything is uniform. > > Of course, the more general you make it, the more likely that it'll be > impossible to optimize well. The point for me is just that range and list partitioning probably need different structure, and hash partitioning, if we want to support that, needs something else again. Range partitioning needs an array of partition boundaries and an array of child OIDs. List partitioning needs an array of specific values and a child table OID for each. Hash partitioning needs something probably quite different. We might be able to do it as a pair of arrays - one of type anyarray and one of type OID - and meet all needs that way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
