#1869 closed defect (fixed)
ST_AsBinary is not unique (again)
Reported by: | nidi | Owned by: | robe |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.0.2 |
Component: | postgis | Version: | 2.0.x |
Keywords: | history | Cc: | erilem |
Description
PostGIS 2 introduced the following behavior again, which has already been resolved in PostGIS 1.5 (see #252):
SELECT ST_AsBinary('POINT(1 2)');
yields
ERROR: function st_asbinary(unknown) is not unique LINE 1: SELECT ST_AsBinary('POINT(1 2)'); ^ HINT: Could not choose a best candidate function. You might need to add explicit type casts.
Explicit type casts do work:
SELECT ST_AsBinary('POINT(1 2)'::geometry); st_asbinary ---------------------------------------------- \x0101000000000000000000f03f0000000000000040 (1 row)
Is the need of explicitely defining the result intended or a regression? If this behavior is intended, libraries such as geoalchemy would need to change query construction.
Change History (11)
comment:1 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Version: | trunk → 2.0.x |
comment:2 by , 12 years ago
I can see this biting a lot of people (heck even our regression tests have issues). I know the solution is for people to fix their apps, but strk -- you think it would be bad if we put in as part of the legacy sql installs
ST_AsBinary(text) , ST_SRID(text) and some of the other common ones. That was the work-around we put in when geography came on the scene. I think we might have taken some of the wrappers out.
At the very least, I guess we should have this in the docs as a breaking change if we don't already.
comment:3 by , 12 years ago
Cc: | added |
---|
Here's a query that works with 1.x and does not work with 2.x:
SELECT anon.lake_id, ST_AsBinary(anon.lake_geom) FROM (SELECT lake.id AS lake_id, ST_AsBinary(lake.geom) AS lake_geom FROM lake WHERE lake.geom IS NULL UNION SELECT lake.id AS lake_id, ST_AsBinary(lake.geom) AS lake_geom FROM lake WHERE lake.geom IS NOT NULL ) AS anon;
The error:
function st_asbinary(bytea) is not unique LINE1: SELECT anon.lake_id, ST_AsBinary(anon... HINT: Could not choose a best candidate function. You might need to add explicit type casts.
comment:4 by , 12 years ago
Milestone: | → PostGIS 2.0.2 |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
Did you install the legacy.sql script? I suspect I may not have added them to legacy since we never came to a consensus what to do.
We decided to take out the overload function and just consider it a legacy issue. It's bad practice to rely on it since raster, geography, and geometry all have ST_AsBinary functions in 2+. I'm willing ot add it to the legacy script though since I think it could bite a lot of people.
comment:5 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:6 by , 12 years ago
I did not install legacy.sql. But I get the same error with legacy.sql installed in my db.
comment:7 by , 12 years ago
So this ticket's description reports about
SELECT ST_AsBinary('POINT(1 2)');
failing with this error:
ERROR: function ST_AsBinary(unknown) is not unique
I've myself reported on a UNION-based query that also fails with a similar, though different error:
ERROR: function ST_AsBinary(bytea) is not unique
Here's a simpler query that triggers the same error:
SELECT As_AsBinary(ST_AsBinary(ST_GeomFromText('POINT(1 2)')));
ST_AsBinary
returns a bytea
, which is a type that ST_AsBinary
does no longer accept as its input argument.
comment:8 by , 12 years ago
ST_AsText
behaves differently, as it does accept text
as input:
SELECT ST_AsText('POINT(1 2)'); st_astext ------------ POINT(1 2) (1 row)
But this is not documented in http://postgis.refractions.net/documentation/manual-2.0/ST_AsText.html.
comment:9 by , 12 years ago
Do we want to add this to legacy or just consider it a documentation bug?
comment:10 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:11 by , 12 years ago
Keywords: | history added |
---|
I think it's intended. Passing an "unknown" to an ST_AsBinary doesn't specify how to interpret the "unknown". Could be a Geography, or a Geometry or a Raster ...