Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99112
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <f9d84857-d2d4-1128-2aa8-381986eebfed@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> <CADxrgCNeqB5XecU=1AwwqbjKZKxLmkyuHfd8BoCc34PdtYs2mQ@mail.gmail.com>
 <f9d84857-d2d4-1128-2aa8-381986eebfed@beccati.com>
Date: Thu, 18 May 2017 14:59:06 +0200
Message-ID: <CADxrgCMct=K-qB+r1jzZbReXBe_Z7qcYQ=TEyB3TuxXJA76zvA@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c0438e056f8c4054fcbf8da"
Subject: Re: [PHP-DEV] Re: [VOTE] PDO Float Type
From: adambaratz@php.net (Adam Baratz)

--94eb2c0438e056f8c4054fcbf8da
Content-Type: text/plain; charset="UTF-8"

>
> 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'm sorry my update sounded like I was ignoring your feedback. Another
change was meant to address your concerns about people misusing
PARAM_FLOAT. Most drivers won't force casts on these values, so if you pass
a string with this type it will work the same as if you used PARAM_STR.
Isn't that the foot-gun you've highlighted?

Maybe we should approach this another way: is there anything that could be
changed with the RFC to change your mind about it? If not, this
conversation is a waste of time for both of us.

> 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.
>

Microsoft actually recommended this solution to my team. We've done only
informal testing, but initial results have been positive.

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?
>

I'm doing this to help my team transition off pdo_dblib. Parameters tagged
with the wrong types are going to make it hard for us to migrate code. I'm
considering #74592 as a general improvement, separately, in my capacity as
pdo_dblib's maintainer, since it's not practical for everyone to move off
it.

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.


I meant if the driver is ever changed to one that uses real prepared
statements.

Thanks,
Adam

--94eb2c0438e056f8c4054fcbf8da--