Hi Adam,
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
I had previously suggested this as a driver-specific change, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542
Please let me know what you think.
Thanks,
Adam
Any thoughts on this one?
It seems like a sensible proposal to me. Two points:
1. Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the
most appropriate names? For one thing, PARAM_STR_ASCII would seem to
imply such strings can only contain ASCII, but that is not the case.
Likewise, PARAM_STR_UNICODE might be understood as being required for
Unicode use, but that is also not the case. Also, both MySQL and MSSQL
refer to such strings as “national” strings, even if they are Unicode
underneath. Would it be better if the terminology we used matched these
databases', for recognisability's sake? That would also resolve
potential confusion with the constant names, they could be e.g.
PARAM_CHAR, ATTR_NATIONAL_CHAR and PARAM_NATIONAL_CHAR, or something
like that.
2. How does this interact with different character sets used for the
connection, if at all?
Thanks!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php