Merging responses here... Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most > appropriate names?
Good point. Maybe instead: - PDO::PARAM_STR_NATL - PDO::ATTR_NATL_STRINGS - PDO::PARAM_STR_CHAR How does this interact with different character sets used for the > connection, if at all? I don't think that should matter. This is strictly a hint for the quote functions to put an "N" at the beginning of their output. DBAL maintainer here: before we introduce even more complexity into the PDO > stuff (which is already a maze), could a set of test cases be written, so > that stuff that is currently impossible to do without this RFC is > clearer/demonstrated? > The other RFC I mentioned included a similar solution to this problem. The PR I put together for that should make this clear enough: https://github.com/php/php-src/pull/2168 > I'm asking because we didn't get any bug reports about extended string > types for Doctrine DBAL, and adding new types just to workaround the > limitations of the usual suspects is shotgun surgery, and just more > complexity to handle. > I think of them more like flags, like PDO::PARAM_INPUT_OUTPUT, than standalone types. Since you apply with a bitwise-OR, the addition would be minimally invasive. And you wouldn't have to rewrite code if you switch drivers. The flags would simply be ignored. (remember that PDO for SQLServer is experimental, if not totally unusable) > I'm mainly interested in pdo_dblib, which is an officially maintained extension (I'm the maintainer). I assume you're referring to pdo_sqlsrv? More importantly, what about allowing arbitrary quote delimiters? https://livesql.oracle.com/apex/livesql/file/content_CIREYU9 > EA54EOKQ7LAMZKRF6P.html This functionality seems orthogonal to what I'm describing. It would be more appropriate to implement this as a driver-specific attribute for pdo_oci. But since that driver doesn't support emulated prepares, I'm not sure how much value it would have. Thanks, Adam
