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
