Andrew Dunstan <andrew@dunslane.net> writes:
> Not sure I understand ... in fact I am sure I don't :-)
> Are you envisioning that the null direction will be able to be selected
> at the time of the select statement?
Yes, of course. My point is that we need to define "operator class" as
"all you need to know about the behavior of a particular index column".
Moving away from that equivalence is just going to mess things up with
no redeeming social benefit.
This looks bad, because the first conclusion is that for any particular
comparison function (eg, int4cmp) you'd want four separate operator
classes, to cover the combinations of ASC-sort and DESC-sort versus
NULLs-high and NULLs-low. But you'd be paying for that complication
somewhere, and ISTM the operator class abstraction is exactly the right
level to pay it at. We could ease the pain for creators of user-defined
types by inventing some mechanism that automatically creates the whole
set of operator classes --- this is another idea that's barely half
baked yet, but I think it ties in nicely with the idea of "operator
class families" to relate opclasses for different datatypes. Basically
I'd like to solve most of these issues by constructing a new layer atop
opclasses, not by deciding that an opclass doesn't convey the full story
about the behavior of an index column.
regards, tom lane
