Re: Range Types, constructors, and the type system
От | Darren Duncan |
---|---|
Тема | Re: Range Types, constructors, and the type system |
Дата | |
Msg-id | 4E081D1A.8060305@darrenduncan.net обсуждение исходный текст |
Ответ на | Re: Range Types, constructors, and the type system (Jeff Davis <pgsql@j-davis.com>) |
Список | 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
В списке pgsql-hackers по дате отправления:
Следующее
От: Dean RasheedДата:
Сообщение: Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch