<[EMAIL PROTECTED]> wrote... : > the OCIQuery that maxim proposed has the advantage of being pretty > high-level, making it much easier for mysql programmers to get a grip at > oracle, but then again i think that every self-respecting php developer > would write a function/method that does this for him ;-). from an > extension point of view i think we shouldn't give up the granularity > IMHO... but if we go for it, maybe we can change the result type (in > accordance to the shift of focus in php5) to be a php object that > contains the statement handle, row+column count,..etc. fields?
Of course everything can be wrapped and modularized. But, I think OCIQuery could be very nice addition in terms of language usability. It would then really make it clear why using OCIParse/Execute. > while we are at it and regarding data types: shall we change the way > lobs are handled? perhaps a switch between object/content return types. > i cannot quite see the advantage of having the lobs loaded on demand, > rather than 'unpacking' them as soon as a result is fetched. I was thinking of also work out a way to start supporting Boolean types. Studying the sources now. This is in regards of Bug #19687: http://bugs.php.net/bug.php?id=19687 > btw, connection pooling, which thies mentioned, would be an absolute +. > > perhaps we should wrap around more oci functions, specially the type > conversion ones, and offer these as part of the extension. Can we have an internal OCI/PHP and viceversa datatype converter? This would make things much easier. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
