On Jun19, 2011, at 00:23 , Jeff Davis wrote:
> On Sat, 2011-06-18 at 22:19 +0200, Florian Pflug wrote:
>> Yes, that seems necessary for consistency. That leaves the question
>> of what to do if someone tries to modify a textrange's collation with
>> a COLLATE clause. For example,
>>
>> For example, whats the result of
>> 'Ä' in '[A,Z']::textrange_german COLLATE 'C'
>> where 'Ä' is a german Umlaut-A which sorts after 'A' but before 'B'
>> in locale 'de_DE' but sorts after 'Z' in locale 'C'. (I'm assuming
>> that textrange_german was defined with collation 'de_DE').
>>
>> With the set-based definition of ranges, the only sensible thing
>> is to simply ignore the COLLATE clause I think.
>
> I think rejecting it makes more sense, so a range would not be a
> collatable type; it just happens to use collations of the subtype
> internally.
Ah, crap, I put the COLLATE in the wrong place. What I actually
had in mind was ('Ä' COLLATE 'C') in '[A,Z]'::textrange_german
I was afraid that the "in" operator cannot distinguish this case
from field in '[A,Z]'::textrange_german
where "field" is declared with "COLLATE 'C'".
In the seconds case, throwing an error seems a bit harsh....
There's also this fun little case field in '[A,Z]'
(note lack of an explicit cast). Here the input function would
probably need to verify that there's a range type corresponding
to the field's type *and* that the range type's collation matches
the field's collation. I wonder if that's possible - Tom said
somewhere that input function don't receive collation information,
though I don't know if that restriction applies in this case.
best regards,
Florian Pflug
