Re: @ versus ~, redux

[ just when you thought it was safe to go back in the water ... ]

"Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> But maybe we should just stick with @> and <@ as per the ltree precedent,
>> and not worry about leaving room for strict inclusion tests.

> +1

OK, nobody objected to that, so I guess we have consensus on the names.
I started looking through the code to see exactly what will be affected,
and here's what I find:

contrib/cube:
a @ b contains
a ~ b is contained by
contrib/intarray:
a @ b contains
a ~ b is contained by
contrib/hstore:
a @ b contains
a ~ b is contained by
contrib/ltree:
a @> b ancestor or equal
a <@ b descendant or equal
ltree also uses ~ and @ for "tree satisfies query", which is pretty close to
the core string types' usage of ~
ltree appears not to need changes

contrib/seg:
a @ b contains
a ~ b is contained by (misdocumented!)
contrib/tsearch2:
a @ b contains
a ~ b is contained by

Core operators:

@(anyarray,anyarray) | arraycontains
@(box,box) | box_contained
@(circle,circle) | circle_contained
@(polygon,polygon) | poly_contained
~(anyarray,anyarray) | arraycontained
~(box,box) | box_contain
~(circle,circle) | circle_contain
~(polygon,polygon) | poly_contain

I was pleased to find out that every one of the above ops is non-strict
containment (ie, equality yields 'true'). So at least we don't have
inconsistency on that point.

I also realized that there are several more core operators using @ and ~
for containment-like comparisons:

@(lseg,box) | on_sb
@(lseg,line) | on_sl
@(point,box) | on_pb
@(point,circle) | pt_contained_circle
@(point,line) | on_pl
@(point,lseg) | on_ps
@(point,path) | on_ppath
@(point,polygon) | pt_contained_poly
~(aclitem[],aclitem) | aclcontains
~(circle,point) | circle_contain_pt
~(path,point) | path_contain_pt
~(polygon,point) | poly_contain_pt

Since these are cross-data-type comparisons, they are arguably not quite
the same animal as the operators listed earlier, which all compare two
objects of the same datatype. I'm inclined to think that these ops
should be renamed too, but does anyone want to argue differently?

In the category of "egad", I found out that the tinterval datatype uses
<< for "contains"! This is simply bizarre --- whether you approve of
the inet-like notation or not, surely the arrows are pointing the wrong
way. Given that tinterval is deprecated and not even documented, maybe
this isn't worth fixing. Any thoughts?

regards, tom lane