If you want to bind a double to a statement, the accepted approach is to
bind as a string:
http://stackoverflow.com/questions/2718628/pdoparam-for-type-decimal
However, this means that prepared statements see these values as strings.
This can cause issues, for example:
http://stackoverflow.com/questions/38105900/sqlite-having-comparison-error
pdo_mysql will actually watch for doubles, but this code will never be
reached since all doubles are cast to strings:
https://github.com/php/php-src/blob/3f25c4228a8f505a000c1ea5751062606247349a/ext/pdo_mysql/mysql_statement.c#L563
Is there a reason PDO::PARAM_DOUBLE doesn't exist?
Thanks,
Adam
Hi,
If you want to bind a double to a statement, the accepted approach is to
bind as a string:
http://stackoverflow.com/questions/2718628/pdoparam-for-type-decimal
For decimal, double wouldn't be the correct type anyway, as it could
cause loss of precision.
Is there a reason PDO::PARAM_DOUBLE doesn't exist?
I don't know if there's am historical reason. I think it should be
there, but to be honest, I'm not sure it's worth the effort at this point.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
For decimal, double wouldn't be the correct type anyway, as it could
cause loss of precision.
Sure, agree the name is imprecise. "Double" is mainly relevant to zvals.
Is there a reason PDO::PARAM_DOUBLE doesn't exist?
I don't know if there's am historical reason. I think it should be
there, but to be honest, I'm not sure it's worth the effort at this point.
Say more on why you don't think there'd be a payoff? I'd think that it
would be worth taking the (I'm guessing) max. 3 days involved to add
missing functionality to a widely-used extension.
Hi Adam,
For decimal, double wouldn't be the correct type anyway, as it could cause loss of precision.Sure, agree the name is imprecise. "Double" is mainly relevant to zvals.
It's not about naming. Double is relevant both to PHP and SQL and is a
floating point type. On the other hand, decimal/numeric fields should be
represented as strings as they are fixed point/precision, which is
something we don't have in stock php. In fact bcmath uses strings too.
> Is there a reason PDO::PARAM_DOUBLE doesn't exist? I don't know if there's am historical reason. I think it should be there, but to be honest, I'm not sure it's worth the effort at this point.Say more on why you don't think there'd be a payoff? I'd think that it
would be worth taking the (I'm guessing) max. 3 days involved to add
missing functionality to a widely-used extension.
I think it would be the biggest PDO API change to date and we should be
very careful. Lots of #ifdefs for pecl pdo_* developers to add, if they
want to keep their extensions backwards compatible.
My biggest worry is its potential misuse for decimal fields. I know this
isn't reason enough for denying an improvement, but there are already
too many people mistakenly using double for currency data and monetary
calculations...
That said, I think this more than anything else requires a proper RFC
and discussion.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
Hi,
Matteo Beccati wrote:
Hi Adam,
For decimal, double wouldn't be the correct type anyway, as it could cause loss of precision.Sure, agree the name is imprecise. "Double" is mainly relevant to zvals.
It's not about naming. Double is relevant both to PHP and SQL and is a
floating point type. On the other hand, decimal/numeric fields should be
represented as strings as they are fixed point/precision, which is
something we don't have in stock php. In fact bcmath uses strings too.
On the subject of naming, if we were to add this, I would think the name
should be PDO::PARAM_FLOAT instead, as that's the more common name for
the PHP float type now. It's IS_DOUBLE internally, but that is mostly an
implementation detail, like IS_LONG.
Thanks.
--
Andrea Faulds
https://ajf.me/