On 13.11.23 21:04, Laurenz Albe wrote:
> On Mon, 2023-11-13 at 10:24 +0100, Peter Eisentraut wrote:
>> * If this table is partitioned and we're creating a unique index, primary
>> * key, or exclusion constraint, make sure that the partition key is a
>> * subset of the index's columns. Otherwise it would be possible to
>> * violate uniqueness by putting values that ought to be unique in
>> * different partitions.
>>
>> But this currently doesn't check that the collations between the
>> partition key and the index definition match. So you can construct a
>> unique index that fails to enforce uniqueness.
>>
>> Here is a partitioned case that doesn't work correctly:
>>
>> create collation case_insensitive (provider=icu,
>> locale='und-u-ks-level2', deterministic=false);
>> create table t1 (a int, b text) partition by hash (b);
>> create table t1a partition of t1 for values with (modulus 2, remainder 0);
>> create table t1b partition of t1 for values with (modulus 2, remainder 1);
>> create unique index i1 on t1 (b collate case_insensitive);
>> insert into t1 values (1, 'a'), (2, 'A'); -- this succeeds
>>
>> The attached patch adds the required collation check. In the example,
>> it would not allow the index i1 to be created.
>
> The patch looks good, but I think the error message needs love:
>
>> + ereport(ERROR,
>> + errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>> + errmsg("collation of column \"%s\" does not match between partition key and index definition",
>> + NameStr(att->attname)));
>
> "does not match between" sounds weird. How about
>
> collation of index column \"%s\" must match collation of the partitioning key column
>
> This will be backpatched, right? What if somebody already created an index like that?
> Does this warrant an entry in the "however" for the release notes, or is the case
> exotic enough that we can assume that nobody is affected?
I think it's exotic enough that I wouldn't bother backpatching it. But
I welcome input on this.