Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98453
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain beccati.com designates 176.9.123.236 as permitted sender)
To: Adam Baratz <adam.baratz@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CADxrgCP4Mt=Jh_zi2qOXEyt2DTbnDFUb2gkxHg8NgeECL5j8_A@mail.gmail.com>
 <CADxrgCNXyWQ+3Uhiq7NECtVMi4EP29Kq_Qryr5rLDgfwGw93xQ@mail.gmail.com>
Message-ID: <afae454c-3df4-7fa2-cf11-111e37d72184@beccati.com>
Date: Thu, 9 Mar 2017 11:03:13 +0100
MIME-Version: 1.0
In-Reply-To: <CADxrgCNXyWQ+3Uhiq7NECtVMi4EP29Kq_Qryr5rLDgfwGw93xQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
From: php@beccati.com (Matteo Beccati)

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?


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/