Re: PDO_DBLIB type handling
| From: | Lester Caine | Date: | Sat, 21 Feb 2015 23:26:01 +0000 |
| Subject: | Re: PDO_DBLIB type handling | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83447@lists.php.net to get a copy of this message | ||
On 21/02/15 22:12, Yasuo Ohgaki wrote:
>> This driver returns all column data as a string, regardless of how it's
>> > represented in the DB. I created a patch for my own use that syncs up the
>> > type handling with the behavior of the MSSQL extension. This seems like it
>> > would be of general use. Does anyone have any feedback before I put
>> > together an RFC? My main question would be whether people would rather have
>> > this be the default/only behavior, or whether it should be opted into
>> > via PDO::ATTR_STRINGIFY_FETCHES.
>> >
> Databases return "string" data to return correct data in DB.
> Most obvious is "NUMERIC" data type. NUMERIC has any precision.
> We may have 128 bit INT in near future also.
>
> So it should return string by default, PHP may convert types into
> PHP native types optionally. Not the other way around. IMHO.
It is probably worth pointing to date and time types as a good example
of where there is not practical to take a binary view of the data since
there are a number of differences between databases, and up until now it
has only been safe to use 32bit numbers directly in PHP which is
additional reasons for keeping to a string base.
( Since all of my material is managed via databases it is also why I am
normally using 'stringy ints'! )
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk