Jeff Davis wrote:
> On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
>> Tom Lane wrote:
>>> Darren Duncan <darren@darrenduncan.net> writes:
>>>> 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.
>>> We've spent years and blood on making sure that Postgres could support
>>> multiple orderings for any datatype; and there are plenty of natural
>>> examples for the usefulness of that. So I'm not at all impressed by
>>> any line of reasoning that starts out by baldly throwing that away.
>> I'm not saying that you can't use multiple orderings with a data type. I'm just
>> saying that the type only has *at most* one (possibly none) *native* ordering,
>> which is what is used when you do something ordered-sensitive with the type,
>> such as have a range.
>
> So, are you saying that it would be impossible to have a range that uses
> a different ordering? What about ORDER BY? What about BTrees?
>
> And if those things can use different orders for the same type, then
> what is the difference between what you are suggesting and a default
> ordering for the type (which we already support)?
>
> I suppose it's hard to tell what you mean by "native".
>
> Regards,
> Jeff Davis
Maybe I'm just talking about "default ordering" then. -- Darren Duncan
