Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98455
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: <afae454c-3df4-7fa2-cf11-111e37d72184@beccati.com>
References: <CADxrgCP4Mt=Jh_zi2qOXEyt2DTbnDFUb2gkxHg8NgeECL5j8_A@mail.gmail.com>
 <CADxrgCNXyWQ+3Uhiq7NECtVMi4EP29Kq_Qryr5rLDgfwGw93xQ@mail.gmail.com> <afae454c-3df4-7fa2-cf11-111e37d72184@beccati.com>
Date: Thu, 9 Mar 2017 09:06:36 -0500
Message-ID: <CADyq6sLPjVtENtpTJHYx2=oH7Qn=-XFiYDbzUNwjTVduDVUYTg@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Adam Baratz <adam.baratz@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114fb312090bce054a4cc235
Subject: Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
From: ocramius@gmail.com (Marco Pivetta)

--001a114fb312090bce054a4cc235
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 9, 2017 at 5:03 AM, Matteo Beccati <php@beccati.com> wrote:

> Hi Adam,
>
> On 03/03/2017 16:47, Adam Baratz wrote:
> >>
> >> Based on some pain points with my team and things I've heard from
> others,
> >> I created an RFC to handle "national" character sets for emulated
> prepared
> >> statements:
> >> https://wiki.php.net/rfc/extended-string-types-for-pdo
> >>
> >
> > Thanks all for the feedback so far. I updated the RFC based on what I
> > heard. Hopefully it clarifies some of the ambiguities mentioned and the
> > motivation for making this change. It's ultimately about helping PDO
> > articulate part of the SQL spec.
> >
> > Let me know if you have any new questions/concerns.
>
> I'm sorry for being late to the party. I too have some doubts, but
> having clarified the fact that national character types are a SQL-92
> standard clears some of them.
>
> 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?
>

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?

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a114fb312090bce054a4cc235--