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/

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