On 02/10/17 01:48, BohwaZ/PHP wrote:
So for me the use case is quite different here, and openBlob allows
stuff that PDO::PARAM_LOB with bindColumn and bindParam cannot allow
currently. In conclusion openBlob is still useful as it allows
accessing
a BLOB outside of a statement and allows to read and write at the same
time without having to load the blob in memory.
This is where the limitations of some of the other database engines
come
into play. In many cases in shared hosting, the database is provided on
another machine, so one has to transfer the data results between
machines and do not have direct access to the data. PDO can't emulate
this function so the question is still SHOULD something that can't be
made generically functional be allowed in PDO. Personally I would
prefer
that for this sort of action the generic driver was used used rather
than PDO and I have to do that for other functions in other databases
currently anyway. So one does not have to overload PDO with more checks
as to if your code will work on the different drivers.
I don't agree with that.
You might want to be able to use a generic abstraction layer such as PDO
to offer support for multiple database engines without having to create
your own abstraction layer with every specific database extension (that
would be huge work) but still be able to access driver-specific features
if available.
This is why I am pushing for PDO to be feature-full, so that you have
the choice to use PDO and not have to implement your own abstraction
layer just because you need one specific feature in one single case :)
If you follow your logic, then PDO::sqliteCreateFunction shouldn't
exist, and this would make the PDO sqlite driver pretty much useless as
SQLite is missing a number of important functions.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
