Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98825
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <d3731396-5033-ed72-221b-987c6841042b@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>
Date: Wed, 19 Apr 2017 18:51:20 -0400
Message-ID: <CADxrgCNgravTxCXWvk8iMDF3XnCyVeuzO7dNzUwN6hrN=FZozA@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=001a1146cc10f988dc054d8cdc6c
Subject: Re: [PHP-DEV] [RFC] PDO Float Type
From: adambaratz@php.net (Adam Baratz)

--001a1146cc10f988dc054d8cdc6c
Content-Type: text/plain; charset=UTF-8

>
> I apologise if I've been harsh, but I am truly disappointed. I tried to
> sway the RFC in a certain direction, that is conveying the pretty basic
> notion that using floating points for fixed precision numbers is wrong:
> there's lots of literature on that and especially why floats shouldn't
> be used to represent money. The result was instead "floats all the
> things!", which is indeed the opposite of what I was expecting.
>

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.

In retrospect, I should've waited to open the vote to make sure everyone
was on the same page about this conclusion. I assumed my explanation was
clearer than it was.

I have no specific suggestion. I'm just worried about the potential
> disruptions of features that benefit a tiny portion of our users.
>

That's fair. I do realize ensuring "significant traction" for new features
is emphasized in the RFC template. That said, small improvements are a nice
way of signaling "active development," especially when very little has
changed in PDO in a long while.

The top Google results for "pdo float param" are three StackOverflow
questions (first from 2009) asking why there isn't a float type, the
PDOStatement::bindValue() documentation, and a feature request on
bugs.php.net (from 2007). Whether or not this RFC is the right approach, I
feel like there has been demand for this. It's a negative signal about the
usefulness of PDO to have feature requests left open for 10 years. If
they're outside the scope of what PDO should do, then let's update the
documentation or whatever to be clearer about that.

While I'm at it, could you please clarify the following for me: Why is
> there so much effort devoted to the legacy dblib driver when pdo_sqlsrv
> seems a much better replacement on paper? Googling for info didn't help,
> so there surely must be something I'm missing here.


Speaking only for myself: legacy reasons. My company uses MSSQL, we have
hundreds of software engineers and a lot of systems that have been attached
to pdo_dblib for a while. We want to get off it in the not-too-distant
future, but for now I'm helping support it.

As far as pdo_sqlsrv goes, it's still a "preview." The Linux ODBC driver it
depends on only became supported in January of this year. Eventually, it
could make sense to deprecate pdo_dblib in favor of something supported by
Microsoft, but the timeline for that is unclear.

Thanks,
Adam

--001a1146cc10f988dc054d8cdc6c--