Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

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