Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers