From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Darren Duncan <darren(at)darrenduncan(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types and extensions |
Date: | 2011-06-20 19:19:04 |
Message-ID: | EE45E2EB-86BA-4367-89FE-D4F07A7E71E4@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun20, 2011, at 20:58 , Tom Lane wrote:
> Darren Duncan <darren(at)darrenduncan(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-06-20 19:44:20 | Re: patch for 9.2: enhanced errors |
Previous Message | Florian Pflug | 2011-06-20 19:15:51 | Re: Another issue with invalid XML values |