Re: Re: [RFC] Extended String Types For PDO
| From: | Marco Pivetta | Date: | Thu, 09 Mar 2017 14:06:36 +0000 |
| Subject: | Re: Re: [RFC] Extended String Types For PDO | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-98455@lists.php.net to get a copy of this message | ||
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/