Hey Adam, On Thu, Mar 9, 2017 at 11:07 AM, Adam Baratz <adam.bar...@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/
