Please correct me where I am wrong. Some query() functions might be actually be unbuffered_query() etc. And while doing such a boring work you tend to make mistakes. Finally I don't know all API's by heart nor have I used all of them.
First of all, in my opinion it would be more useful to concentrate on a true cross-database PHP-level data-object API which can really hide the differences between db implementations, instead of using the exact same function names, and ignoring the implementation differences between the various systems. I'd rather implement buffered queries at the PHP-level for all extensions instead of for Interbase only.
There are some things I'd like to add, mostly concerning the Interbase extension:
- affected_rows
Has been implemented and committed to HEAD.
- bind
mssql_bind()/mysqli_bind_result() are used to bind output parameters to variable references, which is totally different from binding variables values at query execute time. The former is not supported directly by the Interbase API, but could by implemented in the PHP layer.
- data_seek
> - result > - query > - unbuffered_query
Query result buffering in Interbase is carried out by the client library. The only tunable is the buffer count in ibase_connect(). It would be possible to have ibase_query() fetch an entire result and store it internally before returning. This would enable the use of data_seek(), which is currently unsupported, but it would also break BC, as current applications that work with huge result sets would start consuming an awful amount of memory.
Maybe call it buffered_query() and let individual extensions decide which version query() maps to ?
- errno
ifx_error
odbc_error
ora_errorcode
missing in ibase, ingress, mssql, msql, oci, pg, sqlite, sybase
Has been implemented and committed to HEAD as ibase_errcode() :-) (So now is the time for a name change)
- escape_string
missing in fbsql, ifx, ibase, ingress, mssql, msql, odbc, oci, ora,
... and for a reason!
If you use params + binding, the medieval practice of escaping strings is unnecessary. Will probably never be implemented for Interbase.
- fetch_array
- fetch_row
missing in ibase, oci, ora, sqlite
Fetch_row /is/ supported by Interbase.
Is there a distinction in semantics between fetch_row() and fetch_array() ? Don't all the fetch_() functions fetch a row ?
Maybe fetch_row() with a modifier should be an alias for the other fetch functions (like in mysql) This would also allow changing the interfaces without breaking BC.
- insert_id
Cannot be supported by Interbase, because it uses generators and trigger for auto-inc fields. There's a function ibase_gen_id() in HEAD, which can be used to generate an id and insert it manually into the id position. This provides basically the same functionality.
- next_result
only exists in fbsql and mssql
Only makes sense if you allow chained queries. This is not the case in Interbase.
- num_rows
Has been implemented and removed again from HEAD, as the underlying API function returns inconsistent results. Could be re-implemented to work with buffered queries.
- select_db
Has no meaning in Interbase, because you cannot connect to a server without specifying the database.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
