Please find attached a rebased patch with support for pg_dump. I am working on the patch to handle adding a new partition after a default partition by throwing an error if
conflicting rows exist in default partition and adding the partition successfully otherwise. Will post an updated patch by tomorrow.
On Fri, Mar 10, 2017 at 2:17 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 3/2/17 21:40, Robert Haas wrote: >> On the point mentioned above, I >> don't think adding a partition should move tuples, necessarily; seems >> like it would be good enough - maybe better - for it to fail if there >> are any that would need to be moved. > > ISTM that the uses cases of various combinations of adding a default > partition, adding another partition after it, removing the default > partition, clearing out the default partition in order to add more > nondefault partitions, and so on, need to be more clearly spelled out > for each partitioning type. We also need to consider that pg_dump and > pg_upgrade need to be able to reproduce all those states. Seems to be a > bit of work still ...
This patch is only targeting list partitioning. It is not entirely clear that the concept makes sense for range partitioning; you can already define a partition from the end of the last partitioning up to infinity, or from minus-infinity up to the starting point of the first partition. The only thing a default range partition would do is let you do is have a single partition cover all of the ranges that would otherwise be unassigned, which might not even be something we want.
I don't know how complete the patch is, but the specification seems clear enough. If you have partitions for 1, 3, and 5, you get partition constraints of (a = 1), (a = 3), and (a = 5). If you add a default partition, you get a constraint of (a != 1 and a != 3 and a != 5). If you then add a partition for 7, the default partition's constraint becomes (a != 1 and a != 3 and a != 5 and a != 7). The partition must be revalidated at that point for conflicting rows, which we can either try to move to the new partition, or just error out if there are any, depending on what we decide we want to do. I don't think any of that requires any special handling for either pg_dump or pg_upgrade; it all just falls out of getting the partitioning constraints correct and consistently enforcing them, just as for any other partition.