| From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Andreas(dot)Zeugswetter(at)telecom(dot)at (Zeugswetter Andreas DBT) |
| Cc: | pgsql-hackers(at)hub(dot)org |
| Subject: | Re: [HACKERS] = is not always defined as equality is bad |
| Date: | 1998-01-12 13:33:05 |
| Message-ID: | 199801121333.IAA01605@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> 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(at)candle(dot)pha(dot)pa(dot)us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas G. Lockhart | 1998-01-12 13:41:31 | Re: [HACKERS] Re: subselects |
| Previous Message | The Hermit Hacker | 1998-01-12 13:32:26 | Re: New pg_pwd patch and stuff |