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