On Thu, 2007-03-15 at 16:20 -0400, Robert Treat wrote: > Do you find [HSODBC] works well? I've used it from some older Oracle > instances connecting back into PostgreSQL and the results I had have > been flakey at best. For us too. We tried in early 2006 with Oracle 8 via hsodbc to postgresql 7.4.6 and had several problems. From what I remember: - Oracle complained about SQLError when using unixODBC 3.0. This necessitated using 2.5. http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbpgen9/00000291.htm - We had type conversion problems. I can't remember many details of this, but I *think* they may have been text/varchar and timestamp/date. We don't use blobs. - It took our admins a fair bit of time to get working. It probably didn't help that Oracle was running on AIX. - The real nail in the coffin seemed to be that there was no way to push predicates to the remote side. This mean that a remote relation was materialized locally in order to join with local data and that we'd never get reasonable performance for cross-database joins (which, perhaps, it's not designed to do). I'm particularly curious about this last problem. Without pushing predicates to the remote side, it's hard for me to imagine that HSODBC would be terribly useful for anything but building a local warehouse. This seems so odd that I think I must be wrong, but I couldn't find any documentation that to support or discourage cross-database joins. Can someone out there enlighten me? What's the intent for HSODBC and what are its limitations? Can one access remote server side functions via HSODBC (eg, sqlplus> select col1,plpgsqlfx(col1) from remotetable)? Thanks, Reece -- Reece Hart, http://harts.net/reece/, GPG:0x25EC91A0 ./universe -G 6.672e-11 -e 1.602e-19 -protonmass 1.673e-27 -uspres bush kernel warning: universe consuming too many resources. Killing. universe killed due to catastrophic leadership. Try -uspres carter.
