From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: should check collations when creating partitioned index |
Date: | 2023-11-14 16:03:18 |
Message-ID: | ded7b8a5-8ba3-4054-b169-f421aec2fe4f@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-11-14 16:05:35 | Re: Why do indexes and sorts use the database collation? |
Previous Message | Tom Lane | 2023-11-14 15:59:04 | Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro |