Re: Better management of mergejoinable operators

I wrote:
> The real question on the table is whether it's worth distinguishing
> between mergejoinable equality operators and transitive equality
> operators. I suggest that it probably isn't --- do you have any
> examples with more real-world application than the x = 2y case?

The proposal I just sent in effectively eliminates the concept of a
mergejoinable operator as such --- instead, it uses btree opclass
semantics to decide what's mergejoinable. I believe this eliminates
the possibility of using mergejoins for cases like Andrew's x = 2y
operator. Again, has anyone got any real-world examples where it'd
be important to be able to handle such things via mergejoin?

(Note: you can of course mergejoin a query like "WHERE x = 2*y", because
the *operator* is still the vanilla mergejoinable equality. Funny stuff
in the computation of the merge keys isn't a problem.)

regards, tom lane