On Mon, Jun 14, 2010 at 5:38 AM, Stanley Sufficool <ssuffic...@gmail.com>wrote:
> On Sun, Jun 13, 2010 at 3:52 PM, Jared Williams > <jared.willia...@ntlworld.com> wrote: > > > > > >> -----Original Message----- > >> From: Stanley Sufficool [mailto:ssuffic...@gmail.com] > >> Sent: 13 June 2010 20:10 > >> To: Ilia Alshanetsky > >> Cc: Pierre Joye; Denis Gasparin; Matteo Beccati; > >> internals@lists.php.net; pdo > >> Subject: Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New > >> PDO methods for PostgreSQL driver > >> > >> On Sat, Jun 12, 2010 at 4:54 AM, Ilia Alshanetsky > >> <i...@prohost.org> wrote: > >> > The concerns you raised about custom methods specific to database > >> > drivers were not reflective of the PDO's intent as was > >> clarified by Wez and myself. > >> > > >> > The code that was introduced was specific to PostgreSQL, the > > common > >> > functionality was introduced in a way that allows each > >> driver to implement. > >> > >> > >> Yet the rest of the copyFrom, copyTo, etc.. could have ben > >> generic as well. I specifically stated that this could be > >> done at the driver level for FreeTDS using the BCP extensions > >> and/or using "BULK INSERT ". Yet now this is a specific > >> pgsql*** interface that cannot be abstracted for other > >> drivers OR implemented at the driver level. Now if I want a > >> MSSQL / Sybase dump/load method, I need to preface it with > >> dblibCopyFrom, dblibCopyTo. > >> > >> IMHO, every function should be a generic named interface to > >> the driver or statement level and then throw a "not > >> implemented" if the driver does not support it. This will > >> allow for abstraction at a higher level and give the driver > >> developers an opportunity to implement it. It will also give > >> PDO users a more structured way to deal with unsupported > >> methods with try/catch. > >> > >> I know I am a noob to the PDO development process, however I > >> have used OO for quite awhile and I have never seen it DB > >> abstractions implemented like this. > > > > > > But a complete nonsense for a PDO driver maintainer. > > If adds one function to a driver, then you have to had add an function > > to all the rest. > > The interface would start out as "unsupported" / NULL function pointer > in all other drivers and PDO should throw an unsupported as is does > for all the other non-implemented driver interfaces. > > > > > A generic copyFrom or copyTo method should only be added when there is > > enough PDO drivers that behave in exactly the same manner, and to do > > that, you needed specific implementations to test and compare with. > > > > If the dblib methods can't behave the same as the postgres methods, > > then clearly they shouldn't be named the same. > > Yes, DBLIB behaves the same as pgsql in that it performs the copy in a > transaction state and also has it's data visible from the server > perspective. So would SQLite 2.x "COPY", IBM "EXPORT", MySQL "SELECT > ... INTO OUTFILE", etc... > > quoting Denis: "Actually all the methods are wrappers against the native PostgreSQL commands (connection status, copy to/from). I needed to develop them as methods because it is not possible to get the same results with a sql statement (in particular for connection status). It was not possible also for COPY TO/FROM because of the way PostgreSQL handle them ( special functions were developed also for the old pgsql driver)." I don't know sqlite or IBM, but the MySQL SELECT INTO OUTFILE is a plain SQL statement, you don't need any special pdo function to use it, on the other hand, you can't use the postgresql's COPY TO/FROM with PDO without the patch above. Did I misunderstood something? Tyrael
