Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADxrgCP0-fCsvYrCPTssF__WEcqp4ep67xyLksEme3MZKwVS-A@mail.gmail.com>
References: <CADxrgCP4Mt=Jh_zi2qOXEyt2DTbnDFUb2gkxHg8NgeECL5j8_A@mail.gmail.com>
 <CADxrgCNXyWQ+3Uhiq7NECtVMi4EP29Kq_Qryr5rLDgfwGw93xQ@mail.gmail.com>
 <afae454c-3df4-7fa2-cf11-111e37d72184@beccati.com> <CADyq6sLPjVtENtpTJHYx2=oH7Qn=-XFiYDbzUNwjTVduDVUYTg@mail.gmail.com>
 <CADxrgCP0-fCsvYrCPTssF__WEcqp4ep67xyLksEme3MZKwVS-A@mail.gmail.com>
Date: Fri, 10 Mar 2017 01:24:20 -0500
Message-ID: <CADyq6sKixuVZVebpz3dMvn2Db-OnaHrCNQiAG=MeBK977XcEyw@mail.gmail.com>
To: Adam Baratz <adam.baratz@gmail.com>
Cc: Matteo Beccati <php@beccati.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f3c3cb27360054a5a6a76
Subject: Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
From: ocramius@gmail.com (Marco Pivetta)

--001a113f3c3cb27360054a5a6a76
Content-Type: text/plain; charset=UTF-8

Hey Adam,

On Thu, Mar 9, 2017 at 11:07 AM, Adam Baratz <adam.baratz@gmail.com> wrote:

> However, I see no reference about the expected input/output encoding
>> (Unicode data is a bit vague). Is it expected to be UFT-8? Or maybe
>> match the internal encoding of the driver (e.g. UTF-16?)? What happens
>> if I try to quote a latin1 string?
>
>
> I think this is mostly covered by my BC note: "These constants wouldn't
> affect anything related to the character set used for connections." My only
> intentions with my proposed change is to let people prepend an "N" to some
> quoted values. The pdo_mysql and pdo_dblib quote functions are otherwise
> ignorant of encoding. It's all bytes to them. There are different hooks to
> set the encoding for a connection. I'm not aware of issues with either
> extension dealing with multibyte characters in output.
>
> If that doesn't make sense, pass on a code snippet and I can think through
> how it would work.
>
> Since I am still skeptical about this, I asked around and told people to
>> bind parameters with unicode strings and poke me back: works correctly.
>> So what is this addition doing exactly? Shouldn't this be treated as an
>> SQL Server *BUG* instead? Why push it on the toolchain?
>>
>
> It is true that you get the correct result right now. But this happens
> because the DB will automatically cast values that are quoted incorrectly.
> This addition would ensures that quoted values don't have an implicit cast
> applied, which makes queries more expensive. I can put the links I shared
> earlier into the RFC for easier reference.
>
> Thanks,
> Adam
>

I've read the links, hence my skepticism and me labeling this as "yet
another way that SQL Server decides to make things harder and buggy". It is
a bug in SQL Server, unless I'm missing the reason for this to exist (or
maybe there was such a reason in 1991).

As for BC compliance, this will still break code, as current overrides to
prepared statements (in DBAL, specifically) directly compare the parameter
type to a constant (no bitmask comparison).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a113f3c3cb27360054a5a6a76--