[ just when you thought it was safe to go back in the water ... ] "Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster