Ignoring the whole ACS 4.2 vs. OACS 4.5 issue, if I were asked to move a bunch of data from OACS 4.5 Oracle to OACS 4.5 PG I would load the schema from source and only try to migrate data.
The tree sortkey stuff is automatically maintained by triggers so that's not an issue, really. I think what Jon's pointing out is that Sky would have to port over any code they've written as well, and that CONNECT BY queries indeed take some work to port (well, lots of things do, oh, the memories!)
A big problem going from ACS 4.2 Beta to OACS 4.5 (Oracle or PG) is that there's probably enough differences in the initial stuff that's built when loading the core and various package schemas that object numbering won't be 1:1. Ugh, we know for sure they won't be if you don't load schema in exactly the same order.
OK ... this is actually a lot harder than I was thinking. It may almost make sense to from the beginning plan on writing migration scripts as was done to move the openacs.org 3.x site to the new openacs.org 4.x site (Sloan did something similar to move from SloanSpace V1 to dotLRN/SlonSpace V2).
I've pushed the openacs.org 3.x site from PG into OpenACS 4.5 Oracle using these migration scripts, too, just for the hell of it. One of the beauties of AOLserver's letting you define db pools connected to different RDBMSs.
