Re: Range Types, constructors, and the type system - Mailing list pgsql-hackers

Jeff Davis wrote:
> On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
>> I believe that the best general solution here is for every ordered base type to 
>> just have a single total order, which is always used with that type in any 
>> generic order-sensitive operation, including any ranges defined over it, or any 
>> ORDER BY or any <,>,etc.  The built-in generic text type would have exactly 1 
>> system-defined collation that can't be changed, and it would be something simple 
>> and generic, such as simply sorting on the codepoint as integers.
> 
> Well, we're trying to support SQL, and SQL supports collations, so I
> don't think we can just ignore that.

I'm not saying you can't support collations.  See also my reply to Tom.

> I also agree with Tom that it's not a good idea. My reasons are:
> 
>  * Practical considerations, such as having a bunch of cruft from
> duplicated types all over the system. With sufficient changes to the
> type system, maybe that could be overcome. Or perhaps domains could be
> used to make that work for range types (sort of), but the result would
> not be very consistent with the rest of the system.

Yes, duplication can be avoided.

>  * It doesn't seem to be based in any mathematical argument. A type is a
> set of values, and there's no reason it can't have several total orders;
> or no total order at all. So it appears to just be piggybacking on the
> type system infrastructure as a place to hold the metadata for a total
> order.

Yes, I agree that a type is a set of values, and a type can have 0..N total 
orders.  My proposal is just that, for those types that have at least 1 total 
order, exactly 1 of those is defined to be used implicitly in contexts where a 
total order is desired and no explicit collation is given, such as in ranges.

>  * Who's to say that a "compare" function is the only way to specify a
> total order? There might be other interfaces that would support
> something closer to a lexicographic sort. So, from a theoretical
> standpoint, trying to attach a single notion of total order to a type
> seems strange, because there might be multiple interfaces for specifying
> even one total order.

Thank you for bringing this up, the notion of multiple interfaces for specifying 
even one total order.  My example of a compare function was just an example, and 
it is valuable to consider that this may not be the only way to do it.

>  * It would require extra explicit type annotations. If you have 12 text
> types, the only way to practically use any text type is to constantly
> specify which more-specific text type it actually is (probably using
> the :: operator). That is not necessarily a bad choice if starting a
> language from scratch and forming the syntax in a way that it's
> reasonable to do. But this is SQL, and lots of type annotations are
> un-SQL-like.

Well sometimes it doesn't hurt to suggest solutions from the point of view that 
one can start the language from scratch, because that provides a clean way to 
conceptualize and explain a feature.  And then people can find some middle 
ground that adapts benefits from that idea for the feature without changing SQL 
more than needed.  Witness the various improvements to Perl 5 that were first 
expressed in terms of Perl 6.

-- Darren Duncan