Hi Adam, On 24/04/2017 19:46, Adam Baratz wrote: > 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.
Yes, I brought fetching on the table because we should try to be consistent. If numerics are received as strings, they shouldn't be bound as PARAM_FLT, unless the user is willing to potentially lose some information. > 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. Again, there's no limit coming from the C type system: no one is forcing you to cast fixed precision to floating point. In fact it is the opposite: they are normally sent as strings and optionally using the internal (non-float) representation. > 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. If anything, the database libraries will be using their SQL types system as a reference, specifying what is the C-type you can use to send or retrieve data. On the other hand you argue that we should bring low-level decisions to PDO users. > 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. I don't know, but I wouldn't as I've already explained a number of times. If anything, what I see is that very few care. 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
