Craig,
I know it's not what you want (Pg behaving how you expect out of the
box) but creating implicit casts to the desired types will resolve
your immediate issue. You still have to run some Pg-specific code, but
it can be restricted to your DDL where there's (presumably) already
plenty.
My main concern is identifying this issue by PosgtreSQL developers so it
can be addressed as some point in the future. I believe that is done now
and the issue is identified.
As it happens the sql in question is part of a common generic sql script
file where the same script file is run against 10+ different DBMSs to
update the database data from a previous release (all 10+ DBMS schemas
have the same table/column names, logical structure, logical data types,
etc). Having said that, I can introduce a PG-only data update file as a
workaround for PG in this case but not without complicating things quite
a bit. However, due to limited time and schedule, I will be just
accepting the error (based on cost-analysis of the error) in this case.
Best regards,
Farid
On 6/6/2010 11:17 PM, Craig Ringer wrote:
I know it's not what you want (Pg behaving how you expect out of the
box) but creating implicit casts to the desired types will resolve
your immediate issue. You still have to run some Pg-specific code, but
it can be restricted to your DDL where there's (presumably) already
plenty.
See:
http://www.depesz.com/index.php/2008/05/05/error-operator-does-not-exist-integer-text-how-to-fix-it/
http://petereisentraut.blogspot.com/2008/03/readding-implicit-casts-in-postgresql.html
http://wiki.postgresql.org/images/d/d1/Pg83-implicit-casts.sql
--
Craig Ringer
--
www.zidsoft.com <http://www.zidsoft.com/> CompareData: compare and
synchronize SQL DBMS data visually between two databases using ODBC drivers
