Sorry, I don't see the relevance.
The ACS lacks SQL abstraction due to a business decision made by aD. They're only interested in Oracle, and don't want to put in the effort (spend the money) to support an RDBMS-agnostic toolkit.
That's all there is to it. If they'd made a different business decision, the technical task wouldn't overwhelmingly difficult. In a very real sense, the porting problem we face is an artificial one, not in any way intrinsic to the design and implementation of a toolkit like the ACS.
This whole discussion to some degree is based on a strawman argument, i.e. that SQL abstraction is lacking in the ACS for technical reasons.
Now, how exactly will ZPatterns help me to convince aD to abstract out SQL? Or to convince the Postgres development group to up the priority of the implementation of outer joins? Or support me while I do it myself?
We've got some tricks up our sleeves for ACS 4.0 that will ease the porting problem greatly even if aD doesn't take a single step to intentionally help us (they've taken a step in their design that unintentionally helps us). Once outer joins exist in Postgres, porting won't be much of a hassle at all even if aD continues to lace their toolkit with Oracleisms. We'll be translating a bunch of them automatically by hooking into the new database abstraction level they're implementing to solve an entirely different problem.
