Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118033
Message-ID: <c14c541e-105a-59f5-5a44-2e9939ecd7c0@gmail.com>
Date: Tue, 21 Jun 2022 10:41:17 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-GB
To: internals@lists.php.net
References: <CA+kxMuSKYP=favj31kjwkWGC0WWY5rT+RD6H20evQejkr-Nuxw@mail.gmail.com>
 <ba3a1acf-dde0-41aa-904d-681e04c4a7d2@www.fastmail.com>
In-Reply-To: <ba3a1acf-dde0-41aa-904d-681e04c4a7d2@www.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [Under Discussion] PDO driver specific
 sub-classes
From: rowan.collins@gmail.com (Rowan Tommins)

On 21/06/2022 02:25, Larry Garfield wrote:
> * "Should the sub-classes only be avaiable when support for that DB is compiled in?" - I agree, probably not.  Also, "available" is misspelled.
>
> * "Create all DB sub-classes?" - I'd say they all should have subclasses, even if empty.  It's more consistent that way, and you can then also rely on instanceof giving you useful information rather than "well, it's not one of the special ones, so beyond that, NFI."

It's important to remember that PDO drivers are an open set, each 
provided by their own extension. Like any extension, they can be moved 
between php-src, PECL, and private repositories. For example, the 
pdo_sqlsrv driver for SQL Server is provided and actively maintained 
directly by Microsoft.

I think that goes some way to answering these two questions:

* The sub-classes need to be provided by the individual driver 
extensions, because ext/pdo itself can't know which drivers might exist, 
and what methods they might add. So if you don't have a particular 
driver installed, the class will be undefined, just like anything else 
provided by an extension.

* The RFC cannot itself promise to create all possible sub-classes. What 
it can and perhaps should do is mandate that every driver must define 
such a sub-class as part of whatever registration mechanism is used. 
(Logically, that implies that all *bundled* extensions would have the 
sub-class added as part of the RFC's implementation.)


> * Re PQescapeIdentifier - My gut thought is that we should have separate methods for escaping value and identifier in the base class, and then on most DBs they're just identical.  That way it's consistent for anyone building on top of it, because they can rely on escapeValue() and escapeIdentifier() always being The Right Thing To Do without worrying about which DB they're using.


I agree that it should be a generic feature, but it MUST NOT have any 
kind of default implementation. The implementation MUST be written by 
someone with intimate knowledge of the DBMS in question, or it cannot be 
trusted.

The syntax for identifiers varies a lot between and even within DBMSes. 
To use SQL Server as an example, because I have it to hand, "a'b", 
"a''b", and "a\'b" are all different identifiers; but "a""b" and [a"b] 
are different ways of writing the same thing. Select 1 as 'a' is 
accepted as valid syntax; but Create Table Foo ( 'a' int ) is not. There 
are also environment settings that can change some of this behaviour.

So if we only have a Postgres implementation right now, we should either 
implement quoteIdentifier only on PDOPostgres; or implement it on PDO as 
throwing a "not implemented" exception, with PDOPostgres currently the 
only sub-class that over-rides it with a useful implementation.

Regards,

-- 
Rowan Tommins
[IMSoP]