Partitioning CONVERT operations now exposed to a number of restrictions:

1. altered table with subpartitioning is not supported;
2. (CONVERT IN) source table with partitioning is not supported;
3. (CONVERT IN) if the source row fits another partition convert fails;
4. (CONVERT IN) if the source row doesn't fit any partition convert fails;

For p. 1 CONVERT IN is straightforward, data must be routed to correct subpartitions. For CONVERT OUT it may be two variants: 1. result table is partitionined by hash/key like the source table was subpartitioned by same hash/key. This can be fast. 2. result table is not partitioned. This requires data copy.

For p.2 there can be a number of variants as well. 1. we convert the whole partitioned table to a partition by data copy; 2. we convert partitioned table to subpartitioned partition (opposite to p.1 variant 1); 3. we add source partitions to destination table (may require data copy).

For p.4 if the row doesn't fit any partition it should be thrown away. This is how other partitioning alter operations work. This should be controlled by some syntax: either we want that or not.

The operation should be kept fast by default as long as this is possible. If the data copy is required we should check if the algorithm=copy is allowed and fail with error if algorithm=instant was requested.

Currently algorithm= option is not supported for partitioning operations as it is determined by operation type (ADD, DROP fast; REORGANIZE, REBUILD slow).