Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98862
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <36b72547-db1d-125b-62e4-bb3290972dbd@beccati.com>
References: <CADxrgCMB6iz3XX-+yRp0vY0AVWuuL=VwrdLND_78GF0Vhu0K9w@mail.gmail.com>
 <5e3e3e9b-f5b9-a19e-c4cb-6af0f5985d94@beccati.com> <CADxrgCP1wa_HiDCujXZV1oEN0CXDzg32VkWDoOaa17s-+bQ9UQ@mail.gmail.com>
 <be118423-73db-8b1d-3461-91156dd09d54@beccati.com> <CF.A4.18853.7A11DE85@pb1.pair.com>
 <8923084a-a357-91e9-44b5-52a4af0a5df1@beccati.com> <CADxrgCOSCzzLObD0+D02cnYFYySgnKDPoKk8Q-ZZ86QcSsQY8Q@mail.gmail.com>
 <86e4681f-9030-80fc-896b-56255c4b84c7@beccati.com> <CADxrgCPhnMiRZUYJdKV6fPYZoAmmMJrKQCnkaRLOOZ6DvAd-iQ@mail.gmail.com>
 <bc3c313e-66e7-fd73-32ef-dbf991ae4836@beccati.com> <CADxrgCNBjHd_fsvYGwYTeWznWER+FvHseb0nRzF+RvEgQyvVNg@mail.gmail.com>
 <d3731396-5033-ed72-221b-987c6841042b@beccati.com> <CADxrgCNgravTxCXWvk8iMDF3XnCyVeuzO7dNzUwN6hrN=FZozA@mail.gmail.com>
 <36b72547-db1d-125b-62e4-bb3290972dbd@beccati.com>
Date: Mon, 24 Apr 2017 13:46:42 -0400
Message-ID: <CADxrgCNrk7qtOJMmPkzfWkcH_cZc0c7RcpCq1vOBr9=Nj86ncg@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Andrea Faulds <ajf@ajf.me>
Content-Type: multipart/alternative; boundary=001a1146cc10af745d054ded30c4
Subject: Re: [PHP-DEV] [RFC] PDO Float Type
From: adambaratz@php.net (Adam Baratz)

--001a1146cc10af745d054ded30c4
Content-Type: text/plain; charset=UTF-8

>
> 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

--001a1146cc10af745d054ded30c4--