Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98364
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain oracle.com from 156.151.31.81 cause and error)
To: Adam Baratz <adam.baratz@gmail.com>, Andrea Faulds <ajf@ajf.me>,
        Marco Pivetta <ocramius@gmail.com>
References: <CADxrgCP4Mt=Jh_zi2qOXEyt2DTbnDFUb2gkxHg8NgeECL5j8_A@mail.gmail.com>
 <CADxrgCMeLA37V=G1WZixE4bos42j6u0AFaM23sJWzuRi+RdefQ@mail.gmail.com>
 <CADyq6sLh_D3JpBn+MrH55N-q=J4ESzgU1EFpm8HKmbaQrvACyg@mail.gmail.com>
 <CADxrgCMrx88RaX0OQhFh-apZ837pcgX7oKA1KHp8t46++wqNkg@mail.gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <fe709bf6-6686-75b3-168b-1e747813be81@oracle.com>
Date: Wed, 1 Mar 2017 12:02:36 +1100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CADxrgCMrx88RaX0OQhFh-apZ837pcgX7oKA1KHp8t46++wqNkg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------2CDA8997228AC9AFAD027467"
Subject: Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
From: christopher.jones@oracle.com (Christopher Jones)

--------------2CDA8997228AC9AFAD027467
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 1/3/17 12:58 am, Adam Baratz wrote:
> 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 <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_CIREYU9EA54EOKQ7LAMZKRF6P.html
>     <https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.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.

Isn't the same quoting functionality available via the quote() method?  That's what the PR's tests use.

I don't think it's orthogonal.  There are various ways to quote strings and a generic PDO solution should be flexible enough to handle all drivers.

Chris
>
> Thanks,
> Adam

-- 
http://twitter.com/ghrd


--------------2CDA8997228AC9AFAD027467--