On Sun, Jun 19, 2011 at 11:21:28AM +0200, Florian Pflug wrote:
> > 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
Operators don't have to be collation sensetive. If they're not then the
COLLATE in the above statement is redundant. You can decide that an
interval needs an implicit collation and you can just use that.
> 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'".
It should be able to, after all in the first case the collation is
explicit, in the latter implicit.
> 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.
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.
Mvg,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle
