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 :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
