> > 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
