Opened 2 years ago
Closed 14 months ago
#5175 closed defect (fixed)
<> and != on geometry yield operator is not unique
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.5.0 |
Component: | postgis | Version: | 3.0.x |
Keywords: | Cc: |
Description (last modified by )
Reported on IRC someone trying to create a trigger with construct:
(NEW.geom != OLD.geom)
yielded != is not unique for geometry. had to resort to
(NEW.geom::text != OLD.geom::text)
I verified it is an issue with
SELECT ST_Point(1,2) != ST_Point(3,4); SELECT ST_Point(1,2) <> ST_Point(3,4);
However this works fine:
SELECT ST_Point(1,2)::geography != ST_Point(3,4)::geography; SELECT ST_Point(1,2)::geography <> ST_Point(3,4)::geography;
I haven't verified where the extra operator indirection is coming from that is not effecting geography as well.
Note that:
SELECT ST_Point(1,2) = ST_Point(3,4); SELECT NOT (ST_Point(1,2) = ST_Point(3,4)) ;
work without error
Change History (23)
comment:1 by , 2 years ago
Description: | modified (diff) |
---|
comment:2 by , 2 years ago
Milestone: | PostGIS 3.2.2 → PostGIS 3.2.3 |
---|
comment:3 by , 2 years ago
comment:4 by , 2 years ago
Milestone: | PostGIS 3.2.3 → PostGIS 2.5.9 |
---|
comment:5 by , 2 years ago
It just dawned on me where the indirection could be coming from. Remember we have a cast for PostgreSQL geometry types (polygon and point) to postgis types and I think we might have the other way around too.
Could it be because it can cast to text or point and it's getting those extra operators from there. I don't think we have such a cast for geography types.
comment:6 by , 2 years ago
Milestone: | PostGIS 2.5.9 → PostGIS 3.2.4 |
---|
comment:7 by , 2 years ago
Milestone: | PostGIS 3.2.4 → PostGIS 3.4.0 |
---|
comment:8 by , 16 months ago
Milestone: | PostGIS 3.4.0 → PostGIS 3.5.0 |
---|
comment:9 by , 15 months ago
I tried dropping the casts into point, and that didn't change anything.
drop CAST (point AS geometry); drop CAST (geometry AS point);
follow-up: 11 comment:10 by , 15 months ago
I feel kind of stupid this has been open for so long because the solution seems to be just to add an explicit <> operator for geometry.
comment:11 by , 15 months ago
Replying to pramsey:
I feel kind of stupid this has been open for so long because the solution seems to be just to add an explicit <> operator for geometry.
Really? I would never have figured that out
comment:14 by , 15 months ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Please remove from 3.3. We can't be adding signatures in stable releases.
comment:16 by , 15 months ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
gitlab is not happy, registering below https://gitlab.com/postgis/postgis/-/jobs/4870592289#L4164 on the dump restore test
COMMENT ERROR: operator <> already exists ----------------------------------------------------------------------------- make: *** [/builds/postgis/postgis/regress/runtest.mk:24: check-regress] Error 3 Cleaning up project directory and file based variables
perhaps because you are missing an availability notice on geometry_neq (although that shouldn't cause a comment error).
@strk what's missing here?
comment:19 by , 14 months ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Still missing:
- testcase showing the problem being fixed (should fail when that new operator is removed)
- uogradec support (if you add a test you'll see it fail on the woodie upgrade test)
comment:21 by , 14 months ago
Given the side-effect of turning an inequality operator against TopoGeometry ambiguous (see #5546) I'd like to understand what exactly made those operators ambiguous for the core geometry type. I guess ambiguity derives from the presence of implicit casts from the type to some other type. What explicit casts does geometry have ? Did that change any recently ?
comment:22 by , 14 months ago
This shows 3.0.9dev is also affected by the ambiguity:
regress/run_test.pl --extension --upgrade --upgrade-path unpackaged3.0--3.0.9dev -v regress/core/operators
regress/core/operators .. failed (diff expected obtained: /tmp/pgis_reg/test_1_diff) ----------------------------------------------------------------------------- --- regress/core/operators_expected 2023-09-22 10:22:12.097326401 +0200 +++ /tmp/pgis_reg/test_1_out 2023-09-22 10:56:43.854885462 +0200 @@ -44,8 +44,8 @@ eq1|t eq2|f eq3|f -neq1|f -neq2|t +ERROR: operator is not unique: geometry <> geometry at character 40 +ERROR: operator is not unique: geometry <> geometry at character 40 cd1|4 bd1|0 bd2|1
So the reported problem isn't anything new. But the fix moves the ambiguity where previously there wasn't one (TopoGeometry, see #5546)
comment:23 by , 14 months ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Version: | 3.2.x → 3.0.x |
Given CI is green we're obviously not testing the structure of casts so I'll give up on chasing that, especially since I'm sure there are a few of these cases to deal with...
I don't see EVEN ONE definition of <> or !=. so... crazY?