Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98835
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>
Cc: "internals@lists.php.net" <internals@lists.php.net>,
 Andrea Faulds <ajf@ajf.me>
Message-ID: <36b72547-db1d-125b-62e4-bb3290972dbd@beccati.com>
Date: Fri, 21 Apr 2017 13:08:29 +0200
MIME-Version: 1.0
In-Reply-To: <CADxrgCNgravTxCXWvk8iMDF3XnCyVeuzO7dNzUwN6hrN=FZozA@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 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:

https://schlueters.de/blog/archives/182-Types-in-PHP-and-MySQL.html
(search for DECIMAL, applies to mysqli, but the concept is the same)

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.

Also your assertion that "PHP floats are the only built-in type for
these numbers" is not entirely true. I'm perfectly happy to get my fixed
precision numbers as strings and print them as-is or use bcmath or
whatever other means to do some calculations. If I want to, sure I can
cast them to float, but I don't want PDO to start making that choice for me.


> 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 <http://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.

Sure, that's true, although they're not the most popular topics on
StaskOverflow. If we do something about it, I still think we should
strive for more clarity, whereas to me suggesting PARAM_STR for numerics
(instead of PARAM_FLT) is as confusing as having no PARAM_FLT at all.

That's my personal opinion of course. What is a fact though, is that the
RFC isn't accurate and presents PARAM_FLT as the perfect solution for
numerics too, which is plain wrong.


> 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.

Cool, thanks for the clarification.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/