Hi Adam, On 10/04/2017 17:42, Adam Baratz wrote: > Just so I understand your concern, it's that fixed-precision types are > meaningfully different and there could be clashes with other types of > floats? I agree with you on that, but I'm not sure what the right > solution is. There isn't a C type for fixed-precision floats, or even a > PHP type. How would the flow of data work so nothing's lost/altered > along the way? My general thought would be that if fixed-precision > matters, then you should be storing values as strings, that there'd be a > whole other set of pitfalls opened up with a PDO::PARAM_NUMERIC type. > > I realize this is all downsides, which isn't the most constructive way > to respond. Happy to talk through details if you have specific > suggestions for how this type would work in practice.
My concern is that numeric/decimal types should be treated/sent as strings (and eventually dealt with using e.g. bcmath) and not converted to floats, unless one seeks trouble and loves rounding errors, while the new PDO::PARAM_FLOAT const could instead be seen as a good fit to many unexperienced (and some experienced) people. Hence my suggestion of a PDO::PARAM_NUMERIC const that could in fact just be an alias for PDO::PARAM_STR for most of the drivers. The most important thing to me is to discourage the misuse of PDO::PARAM_FLOAT for types that are not actually floating points. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
