> > I apologise if I've been harsh, but I am truly disappointed. I tried to > sway the RFC in a certain direction, that is conveying the pretty basic > notion that using floating points for fixed precision numbers is wrong: > there's lots of literature on that and especially why floats shouldn't > be used to represent money. The result was instead "floats all the > things!", which is indeed the opposite of what I was expecting. >
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. In retrospect, I should've waited to open the vote to make sure everyone was on the same page about this conclusion. I assumed my explanation was clearer than it was. I have no specific suggestion. I'm just worried about the potential > disruptions of features that benefit a tiny portion of our users. > That's fair. I do realize ensuring "significant traction" for new features is emphasized in the RFC template. That said, small improvements are a nice way of signaling "active development," especially when very little has changed in PDO in a long while. 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 (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. While I'm at it, could you please clarify the following for me: Why is > there so much effort devoted to the legacy dblib driver when pdo_sqlsrv > seems a much better replacement on paper? Googling for info didn't help, > so there surely must be something I'm missing here. Speaking only for myself: legacy reasons. My company uses MSSQL, we have hundreds of software engineers and a lot of systems that have been attached to pdo_dblib for a while. We want to get off it in the not-too-distant future, but for now I'm helping support it. 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. Thanks, Adam
