On Jun19, 2011, at 20:08 , Jeff Davis wrote:
> On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
>> Collation checking is generally done by the planner. I don't see why
>> the input function should check, the result of an input function is by
>> definition DEFAULT. It's up to the 'in' operator to check.
>>
>> Note that the whole idea of collation is not really supposed to be
>> assigned to object for storage. How that can be resolved I'm not sure.
>
> I think if we just say that it's a property of the range type
> definition, then that's OK. It's similar to specifying a non-default
> btree opclass for the range type -- it just changes which total order
> the range type adheres to.
In fact, it's exactly the same, because what we *actually* need to
specify is not an opclass but a comparison operator. Which is only
well-defined if you know *both* an opclass *and* a collation.
That reminds me - the conclusion there was that we cannot have
two range types with the same base type but different opclasses,
wasn't it?
AFAIR precisely because otherwise there's no sensible way to handle 'text' in '[lower,upper]'
If I'm not mistaken about this, that would imply that we also cannot
have two range types with the same base type, the same opclass,
but different collations. Which seems rather unfortunate... In fact,
if that's true, maybe restricing range types to the database collation
would be best...
best regards,
Florian Pflug
