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