Peter Eisentraut <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])