From: | Zeugswetter Andreas DBT <Andreas(dot)Zeugswetter(at)telecom(dot)at> |
---|---|
To: | "'pgsql-hackers(at)hub(dot)org'" <pgsql-hackers(at)hub(dot)org> |
Subject: | = is not always defined as equality is bad |
Date: | 1998-01-12 08:12:34 |
Message-ID: | 219F68D65015D011A8E000006F8590C60F2525@sdexcsrv1.sd.spardat.at |
Views: | Raw Message | Whole Thread | 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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim B. Mikheev | 1998-01-12 09:34:45 | Re: [HACKERS] Re: subselects |
Previous Message | Peter T Mount | 1998-01-12 06:58:55 | Re: [HACKERS] Re: New pg_pwd patch and stuff |