Some questions that came to mind while working on PDO/Firebird:
- why can't stmt_get_col() return a zval directly?
- why is there no PDO_PARAM_DOUBLE?
--
Ard
At present it is nearly possible to write extensions that bypass the PDO
php api, and talk directly to the drivers via the PDO Api
- it helps alot that the backends where designed not to return zval's
much (meta is a rather messy exception, that hopefully may get looked at
after 5.1 I guess).
I think Wez, pretty correctly doesnt want to go too far with datatype
abstraction in PDO, I've got some way with making DBDO use PDO as a
backend, and it has a far more comprehensive datatype abstraction. (as
that is one of it's primary focuses.)
But the fact that meta is returning zval's is a bit of a pain, that I've
been putting off dealing with it this week.
Regards
alan
stmt_get_col
.. .stupid evolution deleted stuff ....
--
Alan Knowles <alan@akbkhome.com
Some questions that came to mind while working on PDO/Firebird:
- why can't stmt_get_col() return a zval directly?
- why is there no PDO_PARAM_DOUBLE?
Because PDO doesn't believe in doubles. The decimal data coming back
from most databases is precise decimal data; converting it to double
instantly loses precision.
The idea of get_col() is that you pass back the native C-style type,
and leave it to PDO to manage the creation of a zval, where
appropriate. The simplifies the common cases in developing database
drivers.
--Wez.