Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99092
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: <CADxrgCOpfchXaCKhT_Z1acUZnNmiE1eZ7ZA0JHrTUycHGyKKgA@mail.gmail.com>
 <CADxrgCPAzk6wSfLzRrjBOP7Fyc=GepZde6Z8Vp91UcMbRMiU7w@mail.gmail.com>
 <CADxrgCOb1e7NSNNXYeSWCjPxwkZsVAi77eN6zWSYTw_MrNJb-A@mail.gmail.com>
 <CADxrgCOaRQVkbfgdGEqBSEirvwGywi8g5=4QyN1FapzfEH+XtA@mail.gmail.com>
 <CADxrgCMnDDE-qtrJZ4Z0pR8JQL2XYt1G0-QYT6RdWNVoAx6uAg@mail.gmail.com>
 <f4f8815d-9d53-cca0-f303-919a59d3b041@beccati.com>
 <CADxrgCNeqB5XecU=1AwwqbjKZKxLmkyuHfd8BoCc34PdtYs2mQ@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <f9d84857-d2d4-1128-2aa8-381986eebfed@beccati.com>
Date: Thu, 18 May 2017 07:59:43 +0200
MIME-Version: 1.0
In-Reply-To: <CADxrgCNeqB5XecU=1AwwqbjKZKxLmkyuHfd8BoCc34PdtYs2mQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [VOTE] PDO Float Type
From: php@beccati.com (Matteo Beccati)

Hi Adam,

On 15/05/2017 14:54, Adam Baratz wrote:
>> You can't possibly think that changing the constant name resets the
>> cooldown counter.
> 
> I don't. I posted a new version of the RFC on May 1st. These are the notes
> I sent to this list:
> 
> Most of the discussion in the last round was about fixed precision types.
>> Since there was a lot of disagreement around the right way to handle them,
>> I'd like to keep them out of this RFC. I know Matteo wanted to get them
>> into this RFC, but I'd rather do less if it increases the chances that a
>> group can agree. Nothing in this RFC should interfere with a future
>> implementation of fixed precision types.

If you search the archives, you might find that I wasn't happy to have
PARAM_FLOAT without some kind of PARAM_NUMERIC. You're basically saying
that my point was irrelevant and out of scope. Aww, thanks ;)


> I added a PR to show how this feature would be implemented. It should make
>> it clear that very little change is needed to open up this functionality. I
>> avoided mixing in type casts or any special formatting to keep things safe
>> and simple. This allowed me to streamline the examples in the RFC quite a
>> bit.

The PR could be a 1-liner, but it's the concept behind it that I dislike.


> It would be helpful to get feedback from anyone who voted "no" previously,
>> but didn't comment in the thread. There's no need to talk through this RFC
>> again if everyone in that group wants fixed precision types to be included.
> 
> I think this changes the substance of the proposal, in which case there
> wouldn't need to be a cooldown period. It's okay if you disagree, but you
> can say so much instead of accusing me of acting in bad faith.

You did get feedback and one of the most prominent PDO users around
seems to agree that it's a fairly bad idea. Do you need more?

He also raised concerns about the cooldown period and you are claiming
that this is a brand new RFC because you've cleaned it up and shoved
some of the biggest concerns into the "out of scope" section.


> I don't know how my emails come across. I apologize if I seem antagonistic.
> I'm not trying to rile you up. I'm just an engineer trying to figure out
> how to solve a technical problem. And I'm trying to get a solution that
> will please as many people as possible, including you.

I thank you for your efforts, but, again, out-of-scoping other people's
concerns can't possibly come around as a pleasing solution.

And it's a solution that possibly affects the teeny tiny percentage of
PHP users wanting to optimize queries involving float parameters when
using pdo_dblib. A potential foot-gun for everyone else.


> You could quite easily work around it by embedding your floats in the
>> SQL command string instead. Which is basically what emulated prepares
>> would do for you.
>>
> Yes, that would generate the right query, but it could make it difficult to
> improve its execution plan in the future.
> 
> For example, I'm looking into an approach that would bring real prepared
> statements to pdo_dblib:
> https://bugs.php.net/bug.php?id=74592

No offence, but those look like pretty ugly hacks and poor attempts to
overcome what's a huge limitation of the underlying library.

I understand the power of legacy, since I'm running one very legacy
project myself, but please do yourself a favour and help out the
transition away from something as poor as dblib rather than trying to
build your own custom prepared statement emulator. Maybe your skills and
enthusiasm could be helpful to the pdo_sqlsrv team and the driver could
become core at some point?


> If float parameters aren't bound, each value would result in a new
> execution plan, which would negate a lot of the benefit of having prepared
> statements.

Since your driver uses emulated prepares, I'd expect you having a new
execution plan regardless. At least for current master, which is the RFC
target.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/