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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers