read and write path using different code to locate partition may add code repetition and bring risks

[time-and-fate]

Reproduce

create table t(a varchar(20), b int);
alter table t partition by hash(a) partitions 20;
insert into t value('12345', 10);
select * from t where a = '12345';

> create table t(a varchar(20), b int);
Query OK, 0 rows affected (0.042 sec)

> alter table t partition by hash(a) partitions 20;
Query OK, 0 rows affected, 1 warning (9.200 sec)

> insert into t value('12345', 10);
Query OK, 1 row affected (0.004 sec)

> select * from t where a = '12345';
Empty set (0.007 sec)

The direct cause of this problem is #56094, which means this table should not be created successfully in the first place.

However, this problem exposes one issue: the read path and write path rely on different code to locate the partition for the given value, and they may produce different results.

In the example above, the read path thinks it's in p1 but the write path writes it to p5. You can easily check this by using EXPLAIN and show stats_meta (after waiting for 1 min).

The entry for the write path is (*partitionedTable).locatePartition() in table/tables/partition.go and it handles a row of values. The entry point for the read path is PartitionPruning() in planner/core/partition_prune.go and it handles a filter expression. They are not the same but I believe there are many overlaps.