Thread

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Dmitry Koval <d.koval@postgrespro.ru> — 2025-07-17T07:50:53Z

Hi!

1.
 > bug:
 > ...
 > now pks_d have values(5) for column i, which would violate the
 > cc check constraint.

Probably we shouldn't use a DEFAULT-partition if it wasn't created by
SPLIT PARTITION command, because DEFAULT-partition can has other
restrictions besides CHECK (e.g. FOREIGN KEY).
Corrected.


2.
 > "ALTER TABLE/INDEX ATTACH/DETACH PARTITION" comments need updated.

Updated.


3.
 > SplitPartitionMoveRows
 >   ereport(ERROR,
 >           errcode(ERRCODE_CHECK_VIOLATION),
 >           errmsg("can not find partition for split partition row"),
 >           errtable(splitRel));
 >will this ever be reachable?

In case correct work, there should be no errors. This is insurance.


4.
 >I am not sure the comment "detached DEFAULT partition" is correct.
 >the "constraint" is not ideal, better word would be "partition
 >constraint" or "partition qual".

Corrected.


5.
 >In this case, we could first create the relations pks_3 and pks_4,
 >then detach the partition pks_34


I think it's better not to change the code, because detachPartitionTable
function call should be before performDeletionCheck.
And performDeletionCheck function should be used as soon as possible.


6.
 >should the newly created partitions be based on the split partition
 >or on the partitioned table?
 >In the current v50 implementation, they are based on the partitioned
 >table, but these newly created partitions based on the split partition
 >also make sense.

Yes, now newly created partitions are based on the partitioned.
I think this is more correct: user after SPLIT can modify some of new
partitions as he wants.


7.
 >this ResetExprContext is not needed, if you are evaluate different
 >ExprState again the same slot. See ExecRelCheck also.

Thanks!


8.
 >I did some regress test refactoring to reduce test size.
 >other miscellaneous refactoring is also attached.

Thanks!


P.S. Excuse me, but I can't answer emails for the next three weeks.

-- 
With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com