Re: Tightening selection of default sort/group operators

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> My first thought is that this seems to be an awefully backwards way to
> define operator semantic metadata.

Why? The property we are interested in is that two operators '<' and
'=' will work for grouping --- ie, if you order by '<' and then combine
adjacent values for which '=' succeeds, you will get sane results.
A link between the two pg_operator entries seems a perfectly sensible
way to represent that. The problem I've got is that the code doesn't
(or didn't, till this afternoon) make use of the available information.

> I think we either have to flag operators explicitly ("this is the
> less-than operator"), or we just require that < <= = >= > have certain
> semantics. I could be happy with both.

I'm not totally thrilled with assuming that '=' is the name of the
equality operator. It would be cleaner, probably, to add a column to
pg_type to point to the datatype's equality operator. However, doing
that would pretty much break every existing user-defined type (since
they'd not know they need to specify this additional info) and there are
some circularity problems as well (operator won't exist yet when you do
CREATE TYPE).

Given those problems, I'm willing to stick with the existing assumption
that '=' names an equality operator for grouping. The main point of
this change is to avoid getting burnt by using unrelated '=' and '<'
operators in a context where they need to play together.

regards, tom lane