Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:15118 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91768 invoked by uid 1010); 20 Feb 2005 11:36:14 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 91751 invoked from network); 20 Feb 2005 11:36:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2005 11:36:14 -0000 X-Host-Fingerprint: 212.227.126.176 moutng.kundenserver.de Received: from ([212.227.126.176:64691] helo=moutng.kundenserver.de) by pb1.pair.com (ecelerity 1.2 (r4437)) with SMTP id 0B/B2-12222-E2678124 for ; Sun, 20 Feb 2005 06:36:14 -0500 Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D2pNk-0004Y8-00 for internals@lists.php.net; Sun, 20 Feb 2005 12:36:12 +0100 Received: from [62.224.12.244] (helo=p3EE00CF4.dip0.t-ipconnect.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1D2pNj-0002AD-00 for internals@lists.php.net; Sun, 20 Feb 2005 12:36:11 +0100 To: internals@lists.php.net In-Reply-To: <42185C0B.3000308@php.net> References: <1108836903.316.40.camel@localhost> <42185C0B.3000308@php.net> Content-Type: text/plain Date: Sun, 20 Feb 2005 12:36:01 +0100 Message-ID: <1108899361.316.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:bf648c7cefcb4f7c0e2e63c674feb220 Subject: Re: [PHP-DEV] Re: PDO types From: thekid@thekid.de (Timm Friebe) On Sun, 2005-02-20 at 10:44 +0100, Lukas Smith wrote: > Timm Friebe wrote: > > > while testing PDO I was astonished to see that all values (regardless of > > their types in the database) are returned as strings (in all extensions > > except for PgSQL). Why is that so? It _is_ quite inconsistent, isn't it? > > Wasn't PDO supposed to _unify_ the RDBMS access apis? > > I dont know the actual implementation but at the last meeting we came to > the conclusion that PDO will pass back proper types if the RDBMS does > and strings if the RDBMS doesnt. Anything more would require the users > from providing this metadata or PDO jumping through alot of hoops to > fetch this information from the RDBMS. For pdo_mysql (and probably most others), that's one switch statement to solve them all:) In ext/firebird, the relevant sourcecode is even #ifdef'd out. If PDO extensions would returns numbers (int, float) and booleans as their corresponding PHP datatypes this would save memory. That, for example, was the main motivation I did this in ext/sybase_ct. There, I try a best-match policy: For "integers": * If the number "fits" into a long, it will be returned into a long (PHP datatype integer). This can be done safely for tinyint and shortint, for example. * If the number does not fit, I will try to convert it into a double (PHP datatype float). This is the case for e.g. numeric(10) - values might not fit. This is the same what PHP does when adding 1 to LONG_MAX, for instance. If - in the procedure of doing so, strtod() gives an ERANGE or if the length overflows EG(precision), I will return a string. For "floats" * If the length of the returned value exceeds EG(precision) or if strtod() returns an ERANGE, I will return a string; a float otherwise. While this sound like an awful lot of code, it actually boils down to a couple of lines of C (which will be definitely faster than if users first fetch column metadata and then "cast" dependant on the information they retrieve from that). Talking about that, maybe PDO should start returning Date objects instead of stupid string representations or sequences of numbers of those (where users will start preg_match()ing or strtotime()ing around if they want to do arithmetic with the returned value)... -- Timm If it ain't broken, it doesn't have enough features yet