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

Reply via email to