Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98361
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6sLh_D3JpBn+MrH55N-q=J4ESzgU1EFpm8HKmbaQrvACyg@mail.gmail.com>
References: <CADxrgCP4Mt=Jh_zi2qOXEyt2DTbnDFUb2gkxHg8NgeECL5j8_A@mail.gmail.com>
 <CADxrgCMeLA37V=G1WZixE4bos42j6u0AFaM23sJWzuRi+RdefQ@mail.gmail.com> <CADyq6sLh_D3JpBn+MrH55N-q=J4ESzgU1EFpm8HKmbaQrvACyg@mail.gmail.com>
Date: Tue, 28 Feb 2017 08:58:13 -0500
Message-ID: <CADxrgCMrx88RaX0OQhFh-apZ837pcgX7oKA1KHp8t46++wqNkg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>, Marco Pivetta <ocramius@gmail.com>, 
	Christopher Jones <christopher.jones@oracle.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114633624de4000549979607
Subject: Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO
From: adam.baratz@gmail.com (Adam Baratz)

--001a114633624de4000549979607
Content-Type: text/plain; charset=UTF-8

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


> 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_CIREYU9
> EA54EOKQ7LAMZKRF6P.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.

Thanks,
Adam

--001a114633624de4000549979607--