Re: Range Types and extensions

Tom Lane wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:
>> On Jun20, 2011, at 19:16 , Merlin Moncure wrote:
>>> On Mon, Jun 20, 2011 at 11:21 AM, Jeff Davis <pgsql(at)j-davis(dot)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