Well, having done a bit of php work now (for hire), I feel I can comment on this.
PHP's database API's are not anywhere near as orthogonal as AOLserver's -- one API for MySQL, one API for Oracle, a different API for PostgreSQL. Porting between databases is hard enough as it is -- PHP makes that part much harder.
Although, with ACS 4 this is going to be true with ACS Classic versus OpenACS, too -- unless the OpenACS databases drivers (when more than one exists) 'emulate' the ns_ora call 😊. Which is a big gripe for me -- we'll see how well the new bind variable API stands up to porting, and how the proposed new AOLserver 4 DB API fits in with the ACS 4 API.
aD has basically invented a new DB API for AOLserver under the guise of ns_ora, making it more difficult to port.
I'm looking at the postgres driver now to see about bind variable support (and ns_ora emulation to ease porting), and it appears to be not too difficult, but not too easy, either. It's just putting logic from the tcl code to the C code, in reality.
So, rewritten tcl for the core db API procs may be easier in both the short and long runs -- just how many DB API's support bind variables anyway? A version of the core DB procs for a non-bind-variable database, properly modularized, might help with the porting of ACS 4 to all databases -- bind variable emulation in the drivers might defeat easy porting, unless that code is written in a database-agnostic manner to be easily pulled out of the pg driver and plugged into another driver.
