Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » DB specific PDO subclasses questions. »

DB specific PDO subclasses questions.

php.internals

Dan Ackroyd

4 years ago
Hi, I'm looking at making an RFC for subclassing PDO to expose database specific methods in a less magic way, aka implementing what was discussed here: https://externals.io/message/100773#100813 I have two questions for people who use the PDO with SQLite or Postgres 1. Are any of the functions that are specific to those databases horribly designed and need changing? As the functions would be 'copied across' from where they are now, changes could be made without having horrible BC breaks. That is, are any of these functions horrible to use: PDO::pgsqlCopyFromArray PDO::pgsqlCopyFromFile PDO::pgsqlCopyToArray PDO::pgsqlCopyToFile PDO::pgsqlGetNotify PDO::pgsqlGetPid PDO::pgsqlLOBCreate PDO::pgsqlLOBOpen PDO::pgsqlLOBUnlink SQLIte specific functions: PDO::sqliteCreateAggregate PDO::sqliteCreateCollation PDO::sqliteCreateFunction 2. Other than the SQLite blobOpen functionality, does anyone know of any other functionality that is exposed by SQLite or Postgres that isn't currently exposed through the magic PDO methods? cheers Dan Ack

Benjamin Morel

4 years ago
On Mon, 6 Jun 2022 at 21:15, Dan Ackroyd <Danack@basereality.com> wrote: 2. Other than the SQLite blobOpen functionality, does anyone know of
> any other functionality that is exposed by SQLite or Postgres that > isn't currently exposed through the magic PDO methods? >
Hi, what about the ability to load an extension on SQLite? https://bugs.php.net/bug.php?id=64810 Basically the equivalent of SQLite3::loadExtension() <https://www.php.net/manual/en/sqlite3.loadextension.php> - Benjamin

Dan Ackroyd

4 years ago
On Mon, 6 Jun 2022 at 22:10, Benjamin Morel <benjamin.morel@gmail.com> wrote:
> > Hi, what about the ability to load an extension on SQLite? https://bugs.php.net/bug.php?id=64810 > Basically the equivalent of SQLite3::loadExtension()
Thanks, that's exactly the type of thing that should be looked at being added.
> [2014-09-17 14:55 UTC] benjamin dot morel at gmail dot com > +1 > Definitely a show-stopper!
btw, I admire your patience. cheers Dan Ack

Matteo Beccati

4 years ago
Hi Dan, On 06/06/2022 21:15, Dan Ackroyd wrote:
> Hi, > > I'm looking at making an RFC for subclassing PDO to expose database > specific methods in a less magic way, aka implementing what was > discussed here: https://externals.io/message/100773#100813
Oh, that was a long thread! Not sure what the RFC goal would be, but I'm happy to discuss :)
> I have two questions for people who use the PDO with SQLite or Postgres > > 1. Are any of the functions that are specific to those databases > horribly designed and need changing? As the functions would be 'copied > across' from where they are now, changes could be made without having > horrible BC breaks.
I will check, but...
> That is, are any of these functions horrible to use:
[snip] Not that I know of.
> 2. Other than the SQLite blobOpen functionality, does anyone know of > any other functionality that is exposed by SQLite or Postgres that > isn't currently exposed through the magic PDO methods?
ext/pgsql has plenty of low level functions, e.g. for connection management, more large-object functionality and has async functionalities. For various reasons, none of them seem a good fit for PDO to me: - connection management: a common interface would be best - large objects: mostly obsolete functionality, a PITA to work with - async: better to leave that for PDO2, PDO-ng or PDO++ ;-) Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Philip Hofstetter

4 years ago
Hi, On 6 Jun 2022 at 21:15:12, Dan Ackroyd <Danack@basereality.com> wrote:
> > 2. Other than the SQLite blobOpen functionality, does anyone know of > any other functionality that is exposed by SQLite or Postgres that > isn't currently exposed through the magic PDO methods? >
a wrapper around PQescapeIdentifier in libpq could be useful. The quoting rules for identifiers are different than for values and for values, PDO already has built-in support via PDO::quote() Philip

Matteo Beccati

4 years ago
On 07/06/2022 16:25, Philip Hofstetter wrote:
> a wrapper around PQescapeIdentifier in libpq could be useful. The quoting > rules for identifiers are different than for values and for values, PDO > already has built-in support via PDO::quote()
Indeed, although I feel that would be another useful generic PDO feature, worth its own RFC. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Dan Ackroyd

3 years ago
On Tue, 7 Jun 2022 at 15:25, Philip Hofstetter <phofstetter@sensational.ch> wrote:
> > On 6 Jun 2022 at 21:15:12, Dan Ackroyd <Danack@basereality.com> wrote: >> >> 2. Other than the SQLite blobOpen functionality, does anyone know of >> any other functionality that is exposed by SQLite or Postgres that >> isn't currently exposed through the magic PDO methods? > > a wrapper around PQescapeIdentifier in libpq could be useful.
Okay. Any idea if PQescapeByteaConn should also be added? cheers Dan Ack

Michał Brzuchalski

4 years ago
Hi Dan, pon., 6 cze 2022 o 21:15 Dan Ackroyd <Danack@basereality.com> napisał(a):
> Hi, > > I'm looking at making an RFC for subclassing PDO to expose database > specific methods in a less magic way, aka implementing what was > discussed here: https://externals.io/message/100773#100813 > > I have two questions for people who use the PDO with SQLite or Postgres > > 1. Are any of the functions that are specific to those databases > horribly designed and need changing? As the functions would be 'copied > across' from where they are now, changes could be made without having > horrible BC breaks. > > That is, are any of these functions horrible to use: > > PDO::pgsqlCopyFromArray > PDO::pgsqlCopyFromFile > PDO::pgsqlCopyToArray > PDO::pgsqlCopyToFile > PDO::pgsqlGetNotify > PDO::pgsqlGetPid > PDO::pgsqlLOBCreate > PDO::pgsqlLOBOpen > PDO::pgsqlLOBUnlink > > SQLIte specific functions: > PDO::sqliteCreateAggregate > PDO::sqliteCreateCollation > PDO::sqliteCreateFunction >
I admire you for picking up the gauntlet. Personally, I'm not convinced about these methods being in PDO or in subclasses at all. Since PDO is a non-final class someone could already extend it and build their own functionality around that. If so, then how would it be solved? Auto-magically extending after let's say PDOSqlite3 ?? I'd think of extracting driver-specific methods into a Driver / Platform standalone type like PDODriver / PDOPlatform that is responsible for all driver-specific methods and attributes to carry. That one could be fetched from the PDO instance object with a new dedicated method like "getDriver" / "getPlatform" whatever, maybe a typed read-only property (that would be an interesting option). That way classes like PDOPgSQLDriver or PDOSqlite3Driver might have all the driver methods and avoid introducing new magic related to inheritance. There might be a transition period where these could be proxied like currently in PDO with deprecation error, which allows for a smoother transition. Maybe it is just because of using Doctrine DBAL often, but IMO here a better input might have its contributors. Best regards, Michał Marcin Brzuchalski