Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98873
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain beccati.com designates 176.9.123.236 as permitted sender)
To: Adam Baratz <adambaratz@php.net>
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>
 <CADxrgCNrk7qtOJMmPkzfWkcH_cZc0c7RcpCq1vOBr9=Nj86ncg@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <5b6684df-d8a2-8eea-5908-31beb545a9d1@beccati.com>
Date: Tue, 25 Apr 2017 12:06:57 +0200
MIME-Version: 1.0
In-Reply-To: <CADxrgCNrk7qtOJMmPkzfWkcH_cZc0c7RcpCq1vOBr9=Nj86ncg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] PDO Float Type
From: php@beccati.com (Matteo Beccati)

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/