Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100810
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bohwaz.net designates 5.135.163.151 as permitted sender)
To: Lester Caine <lester@lsces.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 03 Oct 2017 10:48:57 +1300
Cc: internals@lists.php.net
In-Reply-To: <ee13647a-d723-3dcb-24fc-5906ffb58a8c@lsces.co.uk>
References: <25903b1e0fc5a726e44b1e3a5ab4aec4@bohwaz.net>
 <0607d622-caa9-ae1d-33db-1958a0ff0500@gmx.de>
 <20171001185540.5e572e58@platypus>
 <dc5f105093c2613e5cde97f9eb4833ce@bohwaz.net>
 <ee13647a-d723-3dcb-24fc-5906ffb58a8c@lsces.co.uk>
Message-ID: <209262d743236c86c8d66972922fba13@bohwaz.net>
User-Agent: Roundcube Webmail/1.1.5
Subject: Re: [PHP-DEV] Re: [RFC] [Discussion] Implement SQLite "openBlob"  feature in PDO
From: php@bohwaz.net (BohwaZ/PHP)

> 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.