Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99041
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <f4f8815d-9d53-cca0-f303-919a59d3b041@beccati.com>
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>
Date: Mon, 15 May 2017 14:54:20 +0200
Message-ID: <CADxrgCNeqB5XecU=1AwwqbjKZKxLmkyuHfd8BoCc34PdtYs2mQ@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a1146cc10d0048c054f8f8da8"
Subject: Re: [PHP-DEV] Re: [VOTE] PDO Float Type
From: adambaratz@php.net (Adam Baratz)

--001a1146cc10d0048c054f8f8da8
Content-Type: text/plain; charset="UTF-8"

>
> > I had a request on the PR[1] to rename the const, from PDO::PARAM_FLT to
> > PDO::PARAM_FLOAT. Agree that readability is better here. Since there's
> been
> > a change, I'll plan on opening the vote tomorrow.
>
> Are you kidding me?


> 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.
>


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.
>


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.

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.

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

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.

I kept these kinds of details out of the RFC on purpose. I have my use
cases, but the maintainers of the other drivers should decide how they want
to handle floats. I just want to add the hook so the information is there
if anyone wants to use it.

Thanks,
Adam

--001a1146cc10d0048c054f8f8da8--