= is not always defined as equality is bad

Vadim wrote:

but this will be "known bug": this breaks OO-nature of Postgres,

because of

operators can be overrided and '=' can mean s o m e t h i n g (not

equality).

Example: box data type. For boxes, = means equality of _areas_ and =~
means that boxes are the same ==> =~ ANY should be used for IN.

Ok, here I think there should be a restriction to have the = operator
always be defined as equality operator. Because in the long run it will
be hard
to write equality restrictions. a = a1 and b =~ b1 and c +*#~ c1.
Also =, >, <, >= and the like will allways be candidates for use by the
optimizer
(boolean math to simplify restriction or to make an existing index
usable could be used).

I vote for: = must always be defined as equality in user defined types.

(if such comparison is not possible for a special type the = should not
be defined for it)
I therefore also suggest changing the box ops =~ to = and the area = to
some other sign.

Andreas