I believe that's how PDO::PARAM_LOB is intended to work (based on my
reading of the docs and implementations for other drivers). It seems like
more of a convenience than anything, though maybe someone had more ideas
for how it should work across drivers and never got to follow through on it.
This is not how I understand the documentation:
"PDO::PARAM_LOB tells PDO to map the data as a stream, so that you can manipulate it using the PHP Streams API."
But this seems to be quite chaotic, reading
https://secure.php.net/manual/en/pdostatement.bindcolumn.php
"Since information about the columns is not always available to PDO until the statement is executed, portable applications should call this function after PDOStatement::execute().
However, to be able to bind a LOB column as a stream when using the PgSQL driver, applications should call this method before calling PDOStatement::execute(), otherwise the large object OID will be returned as an integer."
This is quite confusing.
And as stated above, with MySQL and SQLite it returns the LOB content as a string on PHP 7+ but a stream handle on PHP 5.6…
To me it seems that the LOB handling of PDO via bindColumn/bindParam is completely broken and inconsistent currently :(
If I have more time available after this RFC I'll look into fixing it for PHP 7.3.
I'd love it if PDO had better BLOB/LOB types and if we had a better
pattern for driver-specific APIs, but I'm comfortable lumping those goals
under "future scope." Getting parity with ext/sqlite3 will make pdo_sqlite
more usable, which will help grow its community, and the number of people
who are able to contribute to these bigger projects. Deprecating the
current set of driver-specific APIs in the future, if we have functional
equivalents, isn't an impossible project.
Yeah sounds good to me :)