Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:45690 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76825 invoked from network); 7 Oct 2009 13:55:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Oct 2009 13:55:15 -0000 Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 88.198.8.16 bigtime.backendmedia.com Linux 2.6 Received: from [88.198.8.16] ([88.198.8.16:43653] helo=bigtime.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A2/7D-13083-1CD9CCA4 for ; Wed, 07 Oct 2009 09:55:14 -0400 Received: from localhost (unknown [127.0.0.1]) by bigtime.backendmedia.com (Postfix) with ESMTP id A5B854144058; Wed, 7 Oct 2009 13:55:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at backendmedia.com Received: from bigtime.backendmedia.com ([127.0.0.1]) by localhost (bigtime.backendmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRh-Daykd0gN; Wed, 7 Oct 2009 15:55:43 +0200 (CEST) Received: from [192.168.80.162] (unknown [195.226.16.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mls@pooteeweet.org) by bigtime.backendmedia.com (Postfix) with ESMTP id E20474144009; Wed, 7 Oct 2009 15:55:42 +0200 (CEST) Cc: Pierre Joye , Samuel ROZE , Christopher Jones , PHP Internals Message-ID: <6E94ABCF-387B-4AD0-BD8A-C59E97291835@pooteeweet.org> To: Matteo Beccati In-Reply-To: <4ACC9C53.9040200@beccati.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Oct 2009 15:55:09 +0200 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> X-Mailer: Apple Mail (2.936) Subject: Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice From: mls@pooteeweet.org (Lukas Kahwe Smith) On 07.10.2009, at 15:49, Matteo Beccati wrote: > 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. > yeah .. its certainly a valid question. we have stuff like lastInsertId(), which depending on the driver either gets the current value of a sequence or the last id generated for the connection. so going by that example unifying things under a common API makes sense if that means that it makes writing portable code easier. so if pgsql and mysql both give warnings that "paranoid" developers might want to interpret as an error whatever, then it seems to make sense to unify this under a common API .. so the key test is not to unify messaging API's but more unify things that are semantically similar. regards, Lukas Kahwe Smith mls@pooteeweet.org