Hi,
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.
Thanks,
Adam
Hi Adam,
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.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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
Hi Adam,
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.
The default behaviour of mysql/pgsql drivers is to convert to the
matching PHP type, if possible. That can be turned off via
PDO::ATTR_STRINGIFY_FETCHES => true.
If PDO_DBLIB doesn't behave like that, I'd say it's a bug that needs to
be fixed, but possibly only applied to a major/minor release due to the
BC break.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi Matteo,
The default behaviour of mysql/pgsql drivers is to convert to the matching
PHP type, if possible. That can be turned off via
PDO::ATTR_STRINGIFY_FETCHES => true.If PDO_DBLIB doesn't behave like that, I'd say it's a bug that needs to be
fixed, but possibly only applied to a major/minor release due to the BC
break.
Please write up RFC now. It's the time :)
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Matteo,
The default behaviour of mysql/pgsql drivers is to convert to the matching
PHP type, if possible. That can be turned off via
PDO::ATTR_STRINGIFY_FETCHES => true.If PDO_DBLIB doesn't behave like that, I'd say it's a bug that needs to be
fixed, but possibly only applied to a major/minor release due to the BC
break.Please write up RFC now. It's the time :)
I'm actually saying that we don't need yet another RFC to fix bugs ;)
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Makes sense to me. (I'm new at how this community works.) Should I include
a patch with the feature request ticket? Should I be working against master?
Hi Matteo,
The default behaviour of mysql/pgsql drivers is to convert to the
matching
PHP type, if possible. That can be turned off via
PDO::ATTR_STRINGIFY_FETCHES => true.If PDO_DBLIB doesn't behave like that, I'd say it's a bug that needs to
be
fixed, but possibly only applied to a major/minor release due to the BC
break.Please write up RFC now. It's the time :)
I'm actually saying that we don't need yet another RFC to fix bugs ;)
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Makes sense to me. (I'm new at how this community works.) Should I include
a patch with the feature request ticket? Should I be working against master?
I'd say you should start by submitting a bug report (if there isn't one
already). Then a pull request on github would probably be easier for
everyone.
Even though the old behaviour should be possible by setting
PDO::ATTR_STRINGIFY_FETCHES to true, it is is a fairly big behaviour
change for PDO_DBLIB, so master-only would be your best bet.
My .02$
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Thanks, I posted a pull request against v5.6.6:
https://github.com/php/php-src/pull/1122
If this goes through, I can do a separate patch against master. (This ext
has changed very little over time so it would be largely the same.)
Makes sense to me. (I'm new at how this community works.) Should I include
a patch with the feature request ticket? Should I be working against
master?I'd say you should start by submitting a bug report (if there isn't one
already). Then a pull request on github would probably be easier for
everyone.Even though the old behaviour should be possible by setting
PDO::ATTR_STRINGIFY_FETCHES to true, it is is a fairly big behaviour change
for PDO_DBLIB, so master-only would be your best bet.My .02$
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/