"Sebastian Nohn" <[EMAIL PROTECTED]> writes: >> 5. Functions are called OCI .* I do well know what it refers to, but >> this is only because I learned the original oci.h API. Wouldn't itbe more >> standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions >> ect? OCI make it a bit confusing, I always heard from my co-workers. >> Besides, this can also be a great input for newer Oracle's updates. > > This is mainly because there are Oracle-funktions and OCI-functions (there > is a difference), and i like the OCI-thing very much, it's much easier and > faster to type than oracle ;)
Well, yes, OCI* functions look pretty geek, indeed, they are very similar (if not identic, in some its parts) to the actual OCI API. But, this naming convention is way not optimal, is limited functionality-wise and, last but not least, it is far not PHP's standard naming convention for the database extensions. In fact, if you'll look into PHP standards specifications (look in CVS: http://cvs.php.net/co.php/php4/CODING_STANDARDS?login=2&r=1.23) you are encoraged using a certain style for calling your functions, especially those of databases since these mostly do the same things. What I meant was, while to access a mySQL database you use mysql_connect(), for PostgreSQL pg_connect() and for Sybase sybase_connect() question stays: why function to connect to Oracle be called OCILogon()? Wouldn't it be better called oracle_connect()? that is how som other programming languages call it. It is not an exaggeration to say that, some programmers are actually making their own functions named this very way so they can easier interact with the Oracle database using their mySQL's (or whatever) habbits because OCI gets them confused. I kind of followed this question within the PHP-Oracle developers I met. For now, we have ora_* and OCI* functions. These are, as long as I understand, used for Oracle v6.* and Oracle v8 (the last one is also 90% compatible with v9). Yet, this shouldn't mean that there is no need for a standarized set of functions like oracle_* with mapped/intuitive functionalities like most of the DBs PHP that supports AND as compatible between Oracle versions as possible. Only this way, one could firmly admit that PHP fully supports Oracle database. Those are my ideas for the Oracle extension. At this point, some new questions arised in my head: 1. Is ora_* extension (ext/oracle) still maintained and ported compatibility-wise to the versions Oracle newer v6 or, for these are OCI8 extensions? If so, then this should mean that ora_* functions are limited to version 6 only, if not deprecated at all. Am I correct, or missed the point? If I guessed, then what was the need for OCI8 extyension at all? Why ora_* could not be continued? I still haven't found it out. 2. What costs merging the two extensions (ora_* and OCI8) in one (oracle_* ?) that fully supports both 6*, 8* and 9* versions of Oracle and remains the only one to be used (as well as maintained, debugged) in the feature? 3. Still, related to question 2: Wouldn't it be safe enough, if not rather strategically clever to introuduce the oracle_* new functions as a new unified extension for Oracle in all its versions within PHP 5? Considering, that we are still at the planning stage of its development release? Hope to see someone to anser, commenting my thoughts on this. I am very much willing contributing to the PHP's Oracle support development. Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
