Re: Range Types and extensions

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

In response to

Responses

Browse pgsql-hackers by date

  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