Re: Range types

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Surely the issue from our POV is whether, given two distinct members of
> a class, we can ever say there is not any intervening member of the
> class according to some ordering. If we can't then next() and prior()
> make no sense for that class.

We would also like to be sure that the answer is not machine-dependent.
For example, you can make such an assertion for two normalized floats
that differ by 1 unit in the last place --- but with a different float
implementation the answer could be different, and anyway a lot of the
really serious problems with float ranges would stem from the range
boundary value probably not being exactly what the user thinks it is.

Also, it's not just "some ordering" that's of interest, it's the natural
one for the datatype. The reason the countability of strings isn't
relevant to us here is that diagonalization or dovetailing counts them
in an ordering that people wouldn't want in practice.

But that brings up something that actually is interesting: should the
range mechanism have a way to identify which btree opclass is considered
to define the type's sort order? Or is it enough to provide ranges in
the type's default ordering?

regards, tom lane