On Mon, May 24, 2010 at 3:07 PM, Pierre Joye <pierre....@gmail.com> wrote: > On Mon, May 24, 2010 at 8:56 PM, Ilia Alshanetsky <i...@prohost.org> wrote: >> Pierre, >> As one of the original authors of PDO that is news to me. PDO was designed >> to allow common functionality to be provided via a common interface, however >> it was also designed to recognize that not all database interfaces are the >> same. >> ... >> Preventing addition of functionality for a driver, just because there are no >> equivalents in other DB interfaces, makes little sense, IMHO.
I 100% agree; see below for more color. > The original specs did not specify any way to do such things in a > clean and nice way. It is also relatively obvious than having drivers > specific features in the "core" PDO was a mistake. I seem to remember writing that down in a spec doc somewhere. In case I'm smoking crack, the convention for driver specific functionality is to prefix those methods with the name of the driver (for example: pgsqlLOBCreate). This should be taken as explicitly allowing for this path; that was our intention when we built PDO. It is in no way a mistake to allow driver specific functions; in fact, quite the opposite; without them, there is no compelling reason for vendors to bother coding support for PDO if they're going to have to add some other vector to enable the full features of their products, and this also extends to users; why use what we've been pushing as the one true way, if it is not in fact the one true way? > I also did not say that we should not have driver specific additions > to PDO but if we do it, we actually need to discuss how we want to do > it. And this discussion has began (w/o much activities) on the PDO > lists. I confess to being busy, but I don't recall any conversation where this capability was revoked or otherwise called out as wrong. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
