On Thu, 2011-06-30 at 09:59 -0700, David E. Wheeler wrote:
> On Jun 30, 2011, at 9:34 AM, Jeff Davis wrote:
>
> > Then how do you get a text range that doesn't correspond to the
> > LC_COLLATE setting?
>
> You cast it.
My original solution was something like this, except involving domains.
With a sufficient amount of casting of all arguments to anything
involving a range type, it works, but it's a little too un-SQL-like.
There was at least one fairly strong objection to my approach, but if
you have some further thoughts along that line, I'm open to suggestion.
Also, what if the LC_COLLATE is C, and you want to cast it to en_US
collation?
range('a','Z')
would be invalid in the C locale, and it would fail before you had a
chance to cast it.
> Cast where you need it explicit, and have a reasonable default when
> it's not cast.
I thought about that, too, but it's not ideal, either. That means that
something might start out as the only range type for a given subtype,
and doesn't need explicit casts. Then you define another range type over
that subtype, and all the original queries break because they are now
ambiguous.
I think the fundamental differences with range types that we're dealing
with are:
1. multiple range types might reasonbly exist for a single subtype
2. the order is a fundamental part of the type definition, not just an
extra argument useful for operations on the range type
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
