Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98353 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13592 invoked from network); 25 Feb 2017 21:53:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2017 21:53:39 -0000 X-Host-Fingerprint: 95.148.67.80 unknown Received: from [95.148.67.80] ([95.148.67.80:19090] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8B/2B-11648-FDCF1B85 for ; Sat, 25 Feb 2017 16:53:37 -0500 Message-ID: <8B.2B.11648.FDCF1B85@pb1.pair.com> To: internals@lists.php.net References: Date: Sat, 25 Feb 2017 21:53:31 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 95.148.67.80 Subject: Re: [RFC] Extended String Types For PDO From: ajf@ajf.me (Andrea Faulds) 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/