Florian Pflug wrote:
> On Jun20, 2011, at 20:58 , Tom Lane wrote:
>> Darren Duncan <darren@darrenduncan.net> writes:
>>> I still think that the most elegant solution is for stuff like collation to just
>>> be built-in to the base types that the range is ranging over, meaning we have a
>>> separate text base type for each text collation, and the text operators are
>>> polymorphic over all those base types. Having collations and stuff as something
>>> off to the side not built-in to text/etc types is the root of the
>>> problem.
>> I tend to agree that this aspect of the SQL standard isn't terribly well
>> designed, but it's the standard and we're stuck with it. We're not
>> going to support two parallel methods of dealing with collations.
>
> Plus, you can always define a DOMAIN for every collation you intent to use,
> and stay clear of COLLATE clauses except as part of these domain definitions.
>
> Most interestingly, this is also the workaround Jeff Davis suggested for
> those who absolutely need two range types over the same base type (i.e.
> define one of the ranges over a domain).
>
> best regards,
> Florian Pflug
That DOMAIN-based solution ostensibly sounds like a good one then, under the
circumstances. What I *don't* want to see is for things like ranges to have
their own collations and the like. From the perspective of all range-specific
things, the types over which they're defined like text should just have their
own native ordering, which defines the range's sense of "before" and "after".
If DOMAIN effectively does that for text types, then that is the way to go. --
Darren Duncan