What does ODBC gain me, again?
I still need to build db-specific queries. The fact that I can tunnel through ODBC to deliver these queries doesn't speed up the porting process. The porting process involves building those queries, not worrying about how I deliver them to the underlying RDMBS.
How does ODBC help me with generic queries that don't need to be ported? Hmmm...not at all, since they're generic and don't need to be ported there's already no work involved. Hard to improve on "zero effort required".
There are only two meaningful issues:
1. how hard is a native driver to write?
2. how much performance do you lose?
As far as #1 goes, the answer typically is "not hard". Avoiding it might be nice, particularly for prototyping a port. As you point out some db's already use essentially ODBC. I believe the external sybase driver is such an example.
External drivers do carry a significant performance hit in the OpenNSD world above and beyond the minor hit imposed by the extra ODBC level. It used to be an order-of-magnitude difference (see old threads of mine at web/db). Jim or Kriston uncovered an embarrassment that enabled them to lower it to a factor of two. That's still a heavy
hit.
Unless you have a threaded ODBC client you'd have to use an external driver.
Now, some db's don't support threaded clients anyway so you'd be stuck using an external driver regardless. In this case ODBC might be just the ticket.
I don't see what this has to do with porting OpenACS 4.x to a different database, though, unless you consider writing a driver to be a significant portion of the effort. I don't, and a driver would be useful to all OpenNSD users, not just the OpenACS 4.x project.
Regardless of driver, generic SQL92 queries will work with no porting effort, while non-generic queries will need to be rewritten into a form acceptable to the underlying RDBMS. The delivery system's not relevant to OpenACS.
