Re: should check collations when creating partitioned index

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.