On Thu, Mar 9, 2017 at 5:03 AM, Matteo Beccati <p...@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/
