Thread

1. = is not always defined as equality is bad

   Zeugswetter Andreas <andreas.zeugswetter@telecom.at> — 1998-01-12T08:12:34Z

   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
   
   

2. Re: [HACKERS] = is not always defined as equality is bad

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-12T13:33:05Z

   > 
   > 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