As Ezequias asked about migrating an application, I'm not quite sure why we're discussing this. Using HSODBC to move data permanently is quite good assuming you have no data type issues.
I missed the OP and therefore the link to app migration. However, HSODBC and its limitations were mentioned and therefore this discussion seems germane. No matter... I've posted this as a new thread.
Perhaps you've implicitly answered my question -- you apparently think HSODBC's primary utility is to "move data permanently". That's fine, but far short of my desire to have a efficient way to expose schema and data in a postgresql database to oracle's clients -- in real time, with pg functions, sane type conversions, and reasonable join performance. I appreciate the challenges of the latter for an optimizer, but it's technically possible (and, psst, could be very lucrative).
I'm not trying to permanently migrate anything, but rather I'm trying to coexist seamlessly with Oracle and lessen the barriers to transitioning to postgresql (or v/v). Interoperability is really the only option when one has to contend with the integration of multiple database apps/schema from multiple developers and with Oracle-specific dependencies, such as I do. Pragmatically speaking, you can't just migrate such a tangle wholesale -- if there's no other route, it'll never happen (and, sniffle, I'll be inextricably bound to Oracle forever).
-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. |
