Skip site navigation (1) Skip section navigation (2)

Re: @ versus ~, redux

From: Michael Glaesemann <grzm(at)seespotcode(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: @ versus ~, redux
Date: 2006-09-04 15:21:50
Message-ID: F26D2A25-1A84-4B87-8927-016810A9F156@seespotcode.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sep 4, 2006, at 23:45 , Tom Lane wrote:

>>   x >>= y  "x contains y"
>>   x >> y   "x strictly contains y"
>>   x <<= y  "x is contained in y"
>>   x << y   "x is strictly contained in y"

(I'd be fine with Andrew's versions. I probably picked them up from  
his ip4r code, now that I think about it.)

> As I commented to Michael, adopting these names for geometric  
> inclusion
> seems unworkable because << and >> already mean "is left of" and "is
> right of" for those datatypes.  We'd have to rename those operators  
> too.

Well, I do have suggestions for those, too :)

r1 </ r2    r1 is to the left of r2 (r1 is before r2)
r1 /> r2    r1 is to the right of r2 (r1 is after r2)


> Also, if we wanted to implement both strict and nonstrict containment
> operators, we're suddenly talking about adding code not only catalog
> entries.

AFAICT, both Andrew and I only include the strict/non-strict versions  
because it's useful to make the distinction for our use cases. If the  
geometric inclusion operators don't make the distinction, I'd assume  
they're inclusive, as that's the more common understanding. Just use  
the one that applies and leave out the other. Granted, it means two  
pairs of reassignments (the to the left/right of and the subset/ 
superset), but if we're breaking it, one more pair isn't that big of  
a deal. And it leaves @ to mean something else.

Michael Glaesemann
grzm seespotcode net



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-09-04 15:29:03
Subject: Re: @ versus ~, redux
Previous:From: Hans-Juergen SchoenigDate: 2006-09-04 15:19:37
Subject: Re: Planner estimates and cast operations ,...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group