Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98456 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27075 invoked from network); 9 Mar 2017 16:07:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2017 16:07:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=adam.baratz@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=adam.baratz@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender) X-PHP-List-Original-Sender: adam.baratz@gmail.com X-Host-Fingerprint: 209.85.223.181 mail-io0-f181.google.com Received: from [209.85.223.181] ([209.85.223.181:36078] helo=mail-io0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 25/83-06022-4CD71C85 for ; Thu, 09 Mar 2017 11:07:33 -0500 Received: by mail-io0-f181.google.com with SMTP id l7so31142820ioe.3 for ; Thu, 09 Mar 2017 08:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HPLGq3AL0lHeX3Tj/CdlK8DdKuAWNprsmDESyiTGNLY=; b=jJsM6t44uOPm+g1dyvEcTBWQx6p1gagG6VTZJhOxEQwcMKxqfMXjnuhTyt8x1RsU7l NQWD6jmirT5PqoNCnWospU8Q1q9g2UTuMPZEneBfF8rwiZC3+vnyJqXC7vVjnKxCezHU myLoybdgglyRJHy/TngqQUmBQfjRTd82WHJLqmAVmOwZYSwqMlkAc9g6/0l4e7Wj342k wUecthZ69Lu1waZYEC3EH2cw2sZDYB8mHpXgf0SmJmoDiiK0sZORWcBigXW2QzBCTmSD p6A2Xvaxu1AtRY15vVWS6xCpnHVceAO/+ffjfnNyBUTt4faYo5QC+1efFfNcaTtYhxbY 407A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HPLGq3AL0lHeX3Tj/CdlK8DdKuAWNprsmDESyiTGNLY=; b=KOu6WLm0mbUUpmds5U4fFA79nCVqTeFFA6kpq1uoY4PFomCyuDzlZ9GTTrm31c0o94 zLs65o+4S8r0F9L69fxisH4NtRgvhyNrpPSjh0ZI84ZjSBSBro2GFyj+tjB7uG054ThP neWCxhXWlvVEupRtw2BE6M8Hq2IBu2ttUbOGuwriA+9Ah07dcc0lz2+KFA3R4ptfi5/r /IiLIdIdhy+lx3FHnrB3B9IL+Jo/If1gklMYf/TdPB1PPf656vCZIKrV8J6f8U+OrbkH oe3H8ucSapfPchvthUhRZhcYd3jEPp8sfhrYewWZChp+YK6osVsBfQyV1LD4BbtnJz2g bOfg== X-Gm-Message-State: AMke39klhqJ8CrlV5+2kInMaFfRUzEDAEZxKt7l9pTPkj+UQjCGj9fZw6hL+lzz3IFy7pJ0UKONIy3Q+aYIp4A== X-Received: by 10.107.180.145 with SMTP id d139mr12104847iof.101.1489075650045; Thu, 09 Mar 2017 08:07:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.82.3 with HTTP; Thu, 9 Mar 2017 08:07:29 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Mar 2017 11:07:29 -0500 Message-ID: To: Marco Pivetta Cc: Matteo Beccati , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=94eb2c05ae0a2a8086054a4e71b4 Subject: Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO From: adam.baratz@gmail.com (Adam Baratz) --94eb2c05ae0a2a8086054a4e71b4 Content-Type: text/plain; charset=UTF-8 > > 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 --94eb2c05ae0a2a8086054a4e71b4--