"I also have a different interpretation of Ben's position. My understanding is that he and other OpenACS people
have ALREADY ported from Oracle to Postgresql, thus removing all Oracle dependencies. The problem as I see
it is how to remain in sync with future upgrades to ACS classic (Oracle) version and extend to supporting other
RDBMs with less pain. My impression was that he does not want "complicated SQL abstraction between Oracle
and Postgres" but believes (as I do) that without RDBM specific SQL the result would be unacceptably inefficient."
OK, you seem to understand our situation fairly well.
There's no need for an overly complex SQL abstraction mechanism, but we certainly would like to see some level of abstraction implemented.
There seems to be a perception that this is a technical problem. It's not, really. There's a bit of a paradox:
If we fork from aD's sources, we could implement a reasonable approach to abstraction ourselves. At worst, we'd just pull the SQL out rather than leave it inline in the scripts. Doing this would lead to the application layer being database agnostic in that they'd call module-specific utility routines to deal with the database. Conceptually equivalent to calling a method in Zope which hides the SQL from the application. This really isn't a big deal (other than there being a lot of application code to visit).
BUT - if we fork from aD's sources, we lose all the major advantage of abstracting out the SQL from the application scripts.
In other words, decoupling from aD's sources doesn't really help us keep in synch with aD's sources ... SQL abstraction only helps us if aD agrees to adopt it.
You see, it's really not a technical problem, at least not in the way some of the newcomers posting here think ...
