Hi Adam, On 20/04/2017 00:51, Adam Baratz wrote: > The reason I went that way was I couldn't find a DB API that > differentiates between the two types. They all represent them as a > double, so it seemed like a needless distinction to create two PDO > types, especially when PHP floats are the only built-in type for these > numbers. Creating a dependency between bcmath and pdo (or something > similar) feels awkward because it would offer false guarantees about > what gets communicated to the DB server.
Sorry, your research wasn't probably as accurate as you think. Certainly libpq doesn't do that and, from what I gather, mysql doesn't either, according to what I read in: https://schlueters.de/blog/archives/182-Types-in-PHP-and-MySQL.html (search for DECIMAL, applies to mysqli, but the concept is the same) If some database APIs aren't capable of properly handling fixed precision, it is their fault (dblib?, firebird?), but PDO shouldn't behave like the less capable ones. Also your assertion that "PHP floats are the only built-in type for these numbers" is not entirely true. I'm perfectly happy to get my fixed precision numbers as strings and print them as-is or use bcmath or whatever other means to do some calculations. If I want to, sure I can cast them to float, but I don't want PDO to start making that choice for me. > The top Google results for "pdo float param" are three StackOverflow > questions (first from 2009) asking why there isn't a float type, the > PDOStatement::bindValue() documentation, and a feature request on > bugs.php.net <http://bugs.php.net> (from 2007). Whether or not this RFC > is the right approach, I feel like there has been demand for this. It's > a negative signal about the usefulness of PDO to have feature requests > left open for 10 years. If they're outside the scope of what PDO should > do, then let's update the documentation or whatever to be clearer about > that. Sure, that's true, although they're not the most popular topics on StaskOverflow. If we do something about it, I still think we should strive for more clarity, whereas to me suggesting PARAM_STR for numerics (instead of PARAM_FLT) is as confusing as having no PARAM_FLT at all. That's my personal opinion of course. What is a fact though, is that the RFC isn't accurate and presents PARAM_FLT as the perfect solution for numerics too, which is plain wrong. > As far as pdo_sqlsrv goes, it's still a "preview." The Linux ODBC driver > it depends on only became supported in January of this year. Eventually, > it could make sense to deprecate pdo_dblib in favor of something > supported by Microsoft, but the timeline for that is unclear. Cool, thanks for the clarification. 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
