DB specific PDO subclasses questions.

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

Hi Dan,

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/

Hi,

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

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