Forum OpenACS Q&A: Response to InterBase port interest
As far as supporting Oracle, IB and PG out of a single code tree, it would be a major undertaking. Specifics regarding PG have been discussed before, and I think Ben's even got something written up somewhere that outlines steps that could be taken.
If queries were split from scripts, all ADP and Tcl scripts could be shared. On the other hand, there's an admitted cost in maintainability and readability in doing such a split, which means it isn't really in aD's interest unless they intend to actively and agressively support IB (which in your business model I presume would mean chasing down web-development business using IB rather than Oracle as the underlying RDBMS).
The scheme to name queries is a compromise that is a bit ugly but helps a lot. In addition, simple abstractions like "how many days old is this table entry?" would serve to isolate differences to a single Tcl proc. This means the IB or PG porting grunt wouldn't have to ferret out each and every query that asks this question, and port it.
Simple things like this would help a LOT. I'm certain Ben's passed on specifics regarding PG to aD in the past.
The new db_* database API will inadvertently help us, because all queries will pass through it, allowing us to regexp queries to mask some differences (we already do this to some degree). This new API is particularly important due to all queries being changed to use "ns_ora" and bind vars rather than generic "ns_db" calls. We plan to think long and hard about inventing ways to translate Oracle queries to their Postgres equivalent within the db_* API layer, in order to minimize the number of changes to Tcl and ADP scripts.
The more we can do this, the more we can use "patch" to upgrade to successive ACS versions - minor update versions, at least.
Sebastian indicated he would be working on a list of IB features/shortcomings etc that would impact a port. I assume he'll include the need to deal with SQLJ, Intermedia etc. It would really be useful if Sebastian were to complete a comprehensive list of stuff he knows are different in the IB and Oracle SQL dialects, and post them here for our education. We could then take a look at the needs of all three databases and start thinking about a strategy for reducing the maintenance load as much as we can given the fact that aD's interest in this is (currently) minimal.