Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:45694 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82363 invoked from network); 7 Oct 2009 14:08:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Oct 2009 14:08:45 -0000 Authentication-Results: pb1.pair.com smtp.mail=samuel.roze@aliceadsl.fr; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=samuel.roze@aliceadsl.fr; sender-id=unknown Received-SPF: error (pb1.pair.com: domain aliceadsl.fr from 212.27.42.3 cause and error) X-PHP-List-Original-Sender: samuel.roze@aliceadsl.fr X-Host-Fingerprint: 212.27.42.3 smtp3-g21.free.fr Linux 2.6 Received: from [212.27.42.3] ([212.27.42.3:37871] helo=smtp3-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CB/AE-13083-AE0ACCA4 for ; Wed, 07 Oct 2009 10:08:45 -0400 Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id C160A8181AE; Wed, 7 Oct 2009 16:08:35 +0200 (CEST) Received: from [192.168.0.10] (lns-bzn-46-82-253-200-55.adsl.proxad.net [82.253.200.55]) by smtp3-g21.free.fr (Postfix) with ESMTP id 0AD738180CE; Wed, 7 Oct 2009 16:08:31 +0200 (CEST) To: Matteo Beccati Cc: Pierre Joye , Christopher Jones , Lukas Kahwe Smith , PHP Internals In-Reply-To: <4ACC9C53.9040200@beccati.com> References: <1254806557.19561.3.camel@samuel-laptop> <1254894205.7418.32.camel@samuel-laptop> <4ACC2B8F.2040302@oracle.com> <4ACC2E8F.8040903@beccati.com> <4ACC2F62.4050601@oracle.com> <4ACC30A3.8030205@beccati.com> <4ACC32E1.6070909@oracle.com> <4ACC3DDE.8020905@beccati.com> <1254914836.7418.52.camel@samuel-laptop> <4ACC9C53.9040200@beccati.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Oct 2009 16:08:46 +0200 Message-ID: <1254924526.566.18.camel@samuel-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice From: samuel.roze@aliceadsl.fr (Samuel ROZE) Actually, PDO want to abstract the communication between the Database and PHP. In "the communication" there are the connection and the querying of tables which raise errors and notices (for many Databases drivers). So, in my mind, it will be a great job to standardise recuperation of theses...although the method to get them is different, that is "the communication" ! Samuel. Le mercredi 07 octobre 2009 à 15:49 +0200, Matteo Beccati a écrit : > Pierre Joye ha scritto: > > On Wed, Oct 7, 2009 at 1:27 PM, Samuel ROZE wrote: > >> This is a bit complicated and very different ! Actually, each database > >> works as it want and it may be better to use different functions for > >> each driver. > > > > That defeats the whole purpose of PDO. The meaning of each message > > will indeed different, but if one needs to call different APIs for > > each driver, I doubt anyone will ever use them. > > Quoting my chat with Rasmus in Verona earlier this year: "PDO is a > database driver abstraction layer, not a database abstraction layer", or > something along the lines, but I see your point ;) > > However, I've been thinking about this a bit more and I think that the > different "message" meanings can be summarised like this: > > * MySQL raises warnings, esp. when not running in strict mode > * Oracle uses them as a custom way to deliver messages/data > * PostgreSQL being a bit of both worlds: informational + custom > > By all means, I like the idea of a unified "message" API, but do we > really need the syntactic sugar (and development effort)? MySQL and > Oracle drivers can already access them with a standard PDO::query() > call. Only PgSQL notices require a special treatment because they are > currently discarded. > > I guess this is becoming more philosophical question: is the base PDO > class intended to only have common and portable functionalities and leve > everything else to the drivers or should it also try and group other > similar features to be more consistent even though not likely to be > portable? > > Also I guess that mixing and matching names could be confusing: an > experienced Oracle developer using "dbms_output" would hardly imagine > that they can be fetched by calling getMessages() just by taking a quick > look to the documentation. Same goes for a Postgres developer who can > easily understand what pg_last_notice() does and would probably not > associate the familiar notice concept with getMessages. > > Sorry for the long post, it's just my 2 cents. > > > Cheers