REORGANIZE PARTITION on a LIST table deletes the rows whose value is no longer in any partition

--source include/have_partition.inc

CREATE TABLE t1 (a INT) PARTITION BY LIST (a) (PARTITION p1 VALUES IN (1,2), PARTITION p3 VALUES IN (3));

INSERT INTO t1 VALUES (1),(2),(3);

# After this, no partition holds the value 2

--error 0,ER_NO_PARTITION_FOR_GIVEN_VALUE,ER_REORG_OUTSIDE_RANGE

ALTER TABLE t1 REORGANIZE PARTITION p1 INTO (PARTITION p1 VALUES IN (1));

--let $n= query_get_value(SELECT COUNT(*) AS n FROM t1, n, 1)

if ($n != 3)

{

  --die REORGANIZE PARTITION took the value 2 out of the LIST partitions and deleted the row 2 without an error

}

DROP TABLE t1;

Leads to:

mysqltest: At line 11: REORGANIZE PARTITION took the value 2 out of the LIST partitions and deleted the row 2 without an error

The ALTER TABLE succeeds with Records: 2 Duplicates: 1 Warnings: 0 and no warning, and the row 2 is gone. InnoDB, LIST COLUMNS and optimized builds give the same result.

The documentation says that REORGANIZE PARTITION can change the value lists of LIST partitions "without losing data" (Partitioning Overview).

The same change as a full ALTER TABLE t1 PARTITION BY LIST (a) (PARTITION p1 VALUES IN (1), PARTITION p3 VALUES IN (3)) fails with ER_NO_PARTITION_FOR_GIVEN_VALUE and keeps the rows. For RANGE partitioning, a REORGANIZE PARTITION that does not cover the old range fails with ER_REORG_OUTSIDE_RANGE.

From the code it seems that ha_partition::copy_partitions() in sql/ha_partition.cc skips a row that fits no new partition and counts it as deleted, and fast_end_partition() in sql/sql_partition.cc reports that count as Duplicates. The ER_REORG_OUTSIDE_RANGE check in prep_alter_part_table() is only done for RANGE partitioning.