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

Mon, 12 Jan 1998 09:12:34 +0100
Zeugswetter Andreas DBT <Andreas.Zeugswetter@telecom.at>
= 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 think each operator in pg_operator has a 'commutative' field for this:

| oprcom                           | oid                              |    4 |


-- 
Bruce Momjian
maillist@candle.pha.pa.us

Mon, 12 Jan 1998 08:33:05 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] = is not always defined as equality is bad