On 23.11.23 11:01, Peter Eisentraut wrote:
> On 20.11.23 17:25, Tom Lane wrote:
>> Peter Eisentraut <peter@eisentraut.org> writes:
>>> On 14.11.23 17:15, Tom Lane wrote:
>>>> I don't love the patch details though. It seems entirely wrong to
>>>> check
>>>> this before we check the opclass match.
>>
>>> Not sure why? The order doesn't seem to matter?
>>
>> The case that was bothering me was if we had a non-collated type
>> versus a collated type. That would result in throwing an error
>> about collation mismatch, when complaining about the opclass seems
>> more apropos. However, if we do this:
>>
>>> I see. That means we shouldn't raise an error on a mismatch but just do
>>> if (key->partcollation[i] != collationIds[j])
>>> continue;
>>
>> it might not matter much.
>
> Here is an updated patch that works as indicated above.
>
> The behavior if you try to create an index with mismatching collations
> now is that it will skip over the column and complain at the end with
> something like
>
> ERROR: 0A000: unique constraint on partitioned table must include all
> partitioning columns
> DETAIL: UNIQUE constraint on table "t1" lacks column "b" which is part
> of the partition key.
>
> which perhaps isn't intuitive, but I think it would be the same if you
> somehow tried to build an index with different operator classes than the
> partitioning. I think these less-specific error messages are ok in such
> edge cases.
If there are no further comments on this patch version, I plan to go
ahead and commit it soon.
