That is entertaining. The text->geometry cast is implicit, but so are
the casts text->character, text->character varying, text->name,
text->regclass. The issue seems to be that the only cast defined on
bytea is to bytea->geometry. With no implicit casts for text->bytea or
bytea->text, the only way the equality can be evaluated is through the
geometry type.
This is just another case of needing to be explicit in what you ask for.
Try select 'abc'::text = decode('YWJj', 'base64')::text or select
'abc'::bytea = decode('YWJj', 'base64') to avoid the automatic geometry
castings.
Mark Leslie
Geospatial Software Architect
LISAsoft
-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------
LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com
Charlie Savage wrote:
Install postgis and make sure it is on your search path.
Then run this query:
select 'abc'::text = decode('YWJj', 'base64')
Its results in this:
ERROR: parse error - invalid geometry
********** Error **********
ERROR: parse error - invalid geometry
SQL state: XX000
I see that postgis defines the = operator between two geometries. Which
seems to mean that the text on the left side is converted automatically
to a geometry and the bytea on the right side to a geometry
automatically. That's surprising to say the least...
Charlie
------------------------------------------------------------------------
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
