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 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. * 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. * 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. * 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. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers