Hello everybody.
I just stumbled on an oci bug (piecewise saving data to lobs eats one
char for every piece) that has been fixed in the pecl version of the oci
extension, starting from rev. 1.0, and in the bundled php extension,
starting with php 5.1.6.
Needless to say, the only way to code around this bug is to either test
for it or grep through phpinfo() for specific oci version strings (since
the current php install might be using the bundled oci ext or not). Oh,
and the fix was never announced in either the pecl or php changelogs...
In the past I have come across similar situations with xmlrpc and json
extensions changing their apis or simply fixing their bugs in a way that
makes php library writers want to pull their hair out.
Yesterday I dug out in the php manual and code, and found out that the
phpversion() php function in fact looks like it was designed from the
ground up to give coders an exact version number of every single
extension in use, be it from pecl, php or anywhere else.
It just needs extension maintainers to kindly put a meaningful version
string - any will do - in their zend_module_entry structure, instead of
NO_VERSION_YET.
It does not look like a huge amount of work to me, so I really am
wondering what I am missing here... maybe a formal declaration from the
core devs that extensions not providing a version info will not be
accepted anymore, starting NOW?
Thanks
Gaetano Giunta