>
> 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

Reply via email to