Re: Range Types and extensions - Mailing list pgsql-hackers

From Darren Duncan
Subject Re: Range Types and extensions
Date
Msg-id 4DFF93C2.2030500@darrenduncan.net
Whole thread Raw
In response to Re: Range Types and extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Range Types and extensions
List pgsql-hackers
Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
>>> On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis <pgsql@j-davis.com> wrote:
>>> hm, what if there *was( only one range type per base type, but in the
>>> various contexts where specific ordering and collation was important
>>> you could optionally pass them in?  Meaning, the specific ordering was
>>> not bound rigidly to the type, but to the operation?
> 
>> I suggested that previously here
>>   http://archives.postgresql.org/pgsql-hackers/2011-06/msg00846.php
> 
>> In the ensuing discussion, however, it became clear that by doing so
>> range types become little more than a pair of values. More specifically,
>> a range then *doesn't* represent a set of values, because whether or
>> not a value is "in" the range depends on a specific sort order.
> 
> Yeah, that doesn't seem like the way to go.  If a range value doesn't
> represent a well-defined set of base-type values, we lose a lot of the
> mathematical underpinnings for range operations.
> 
> So ... just how awful would it be if we hard-wired range types to always
> use their base type's default btree sort ordering and the database's
> default collation?  In principle that sucks, but I'm not sure how wide
> the use-cases actually will be for other choices.
> 
> The other viable alternative seems to be to require those two properties
> (btree opclass and collation) to be part of a specific range type
> definition.  The complaint about that seemed to be that we couldn't
> infer an ANYRANGE type given only ANYELEMENT, but could we alleviate
> that by identifying one range type as the default for the base type,
> and then using that one in cases where we have no ANYRANGE input?
> 
>             regards, tom lane

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.  The 
range-specific stuff can remain ANYELEMENT and no special-casing is required. 
Also, besides range constructors, a generic membership test like "value in 
range" is polymorphic. -- Darren Duncan


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Another issue with invalid XML values
Next
From: Greg Smith
Date:
Subject: Re: pgbench--new transaction type