On Mon, Nov 23, 2015 at 1:44 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> I support building incrementally, but I don't see why we want to >> change the catalog structure and then change it again. That seems >> like it makes the project more work, not less. > > I agree with what you say. I thought you were saying that the > implementation had to provide multi-partitioning from the get-go, not > just the design.
Well, I *hope* that's going to fall out naturally. If it doesn't, I can live with that. But I hope it will. >> To me, it seems like there is a pretty obvious approach here: each >> table can be either a plain table, or a partition root (which can look >> just like an empty inheritance parent). Then multi-level partitioning >> falls right out of that design without needing to do anything extra. > > Sounds reasonable. Cool. >> I think it is also worth getting the syntax right from the beginning. > > Yes, that's critical. We could implement the whole thing in gram.y and > then have the unsupported cases throw errors; then it's easy to see that > there are no grammar conflicts to deal with later. That's worth considering, too. -- 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