>> 3. >> + longer satisfy the partition constraint of the containing partition. In >> that >> + case, if there is some other partition in the partition tree for which >> this >> + row satisfies its partition constraint, then the row is moved to that >> + partition. If there isn't such a partition, an error will occur. >> >> Doesn't this error case indicate that this needs to be integrated with >> Default partition patch of Rahila or that patch needs to take care >> this error case? >> Basically, if there is no matching partition, then move it to default >> partition. > > Will have a look on this. Thanks for pointing this out.
I tried update row movement with both my patch and default-partition patch applied. And it looks like it works as expected : 1. When an update changes the partitioned key such that the row does not fit into any of the non-default partitions, the row is moved to the default partition. 2. If the row does fit into a non-default partition, the row moves into that partition. 3. If a row from a default partition is updated such that it fits into any of the non-default partition, it moves into that partition. I think we can debate on whether the row should stay in the default partition or move. I think it should be moved, since now the row has a suitable partition. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
