> > 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: >
I think we're talking about different things. I'm talking about binding parameters. It seems like you're talking about fetching column data. You are correct that fixed-precision values are typically fetched as strings. One thing to note is that this can be a choice made by the PDO driver extension. With libpq, PQgetvalue[1] returns all column data as strings. If you look at pgsql_stmt_get_col, you'll see extra logic to cast to a zend_bool or zend_long. Other drivers, like pdo_odbc, fetch everything as a string. 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. > I wrote in the RFC how each API works. They all lack this ability, because they're all limited by the C type system. This is why I was arguing to merge floats and fixed-precision types. It's a difference that doesn't exist when sending data to the database. I'll admit I wasn't paying a lot of attention to retrieving data. There's a lot of variability between PDO drivers and I didn't want to complicate the scope of the RFC. If I can summarize our underlying arguments, mine is that PDO parameters should correspond to zval types and C types, yours is that PDO parameters should correspond to database column types. A lot of PDO internals tend to assume the former, even if the latter is the conventional wisdom. Honestly, I'm not very attached to having a single type for floats and fixed-precision. If this RFC doesn't pass, which it doesn't look like it will, I would be just as happy to cut fixed-precision values out of it. Though I don't have a good handle on how many of the people who voted "no" would change their minds if fixed-precision was simply left out of scope. Thanks, Adam --- [1] https://www.postgresql.org/docs/9.6/static/libpq-exec.ht ml#LIBPQ-PQGETVALUE
