[postgis-devel] Death to Pointless Operators

Paragon Corporation lr at pcorp.us
Sun Dec 19 08:59:20 PST 2010


=  would mean bounding box equals as it does now except it would take
advantage of a gist index where it can.  I don't think we can change that.
Its consistent with all operators are bounding box checks.

So regardless of if its doing btree / gist it should mean the same thing is
my point.

The distinctions look like just implementation artifacts I as a user don't
really care to know about.

My concern with keeping ~ going is that its broken in the sense that if you
are a long time user of PostGIS and actualy used it  you still have in your
mind that it means geometric equality.

When you port your apps over from say 1.3 (even 1.4 and 1.5 if you had done
a soft upgrade) -- the meaning of it has suddenly changed.

Your apps aren't breaking -- there just returning the wrong answers which is
much harder to debug than to get back a " I'm sorry  ~ doesn't exist."

R

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Sunday, December 19, 2010 11:38 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Death to Pointless Operators

Would '=' be equivalent to ST_Equals, ST_OrderingEquals or
bounding-box-equals?
P

On Sun, Dec 19, 2010 at 7:32 AM, Paragon Corporation <lr at pcorp.us> wrote:
> :
>
>>> If you get rid of anything you should really get rid of that ~ -- 
>>> its just confusing because it means something completely different 
>>> as Nicklas mentioned a while ago (when you are talking about the 
>>> built-in polygon/point and I think even pgsphere --
>>
>> ~ is the opposite of @. But it can be any symbol we like. How about !@ ?
>>
>
>> Actually that would be a bad symbol pairing (the equals/notequals 
>> parallel
> is not correct, A = B does not imply B != A). A better one would be if 
> we used >> and << since they are commutative relations.
>> But that would break backwards compatibility which above you are 
>> telling
> me is a big deal for the operators that people don't actually use!
>
>> So, for sheer conservative curmudgoenliness, I would suggest we leave 
>> ~
> and @ as they are.
>
>
> Like I said if we can I would prefer to overload the = operator like 
> ltree does so I don't have to go around explaining why we have ~ and = 
> which mean the same thing but one uses an index and one doesn't.
> Or you think there is a benefit there of keeping them separate?
>
> http://www.postgresql.org/docs/current/interactive/ltree.html
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel





More information about the postgis-devel mailing list