From:	Ulf Wendel	Date:	Wed May  7 07:01:22 2008
Subject:	Re: [PDO] PDO version 1 improvements

Lukas Kahwe Smith schrieb:
> 
> On 06.05.2008, at 21:17, Ulf Wendel wrote:
>> - don't emulate named parameters if the driver does not support it
>>  I wonder if named parameters are part of any SQL standard and why PDO 
>> once again ignores the world outside and tries to emulate stuff not 
>> all databases support to end up in a poor emulation.
> 
> I am not sure that prepared statements are part of the standard at all. 
> most rdbms simply followed odbc. postgresql and oracle both have their 
> own syntax. in order to make it possible to write portable code, at the 
> very least parsing and rewriting to these two rdbms must be supported. 
> that being said, i think the postgresql and oracle syntax is the most 
> flexible (allows reusing the same parameter multiple times) and also the 
> more readable (since placeholders may be named). So I do not agree that 
> this is a bad feature. I do agree that the parser is way too simplistic 

That's the wrong way around. For portable code one should aim to use the 
least common denominator. PDO aims to support the most convenient syntax 
for the developer regardless of the support by the database vendors. 
Don't be surprised if you end up with something that allows you to write 
beautiful code but does not fly.

PDO ignores portability by supporting unportable SQL syntax. This is a 
strange approach for a data access abstration layer (API abstraction not 
SQL level abstraction).

PDO does not bother about other differences in SQL dialects and stuff 
inbetween the API and the SQL dialect but about named vs. ordinal 
parameters. For example, PDO::lastInsertId() may or may not return 
anything meaningful depending on the driver.

The course of PDO is not clear to me. PDO should not call itself a data 
access abstraction layer if it aims to be more than that. Support for 
named parameters is part of a SQL abstraction layer. Its strange for me 
to see that a convenience feature like named parameters is a must and a 
- in my eyes - basic and more important feature like lastInsertId() gets 
ignored.

Users should be aware of all the emulation going on and taught carefully 
about the consequences. Maybe a writing PDO class would be a good 
addition to the RFC/TODO list.

And, AFAIK, JDBC does not guarantee that you can use named parameters 
with prepared statements. JDBC 3.0 has added named parameters support 
for callable statements but not for prepared statements.

> and this is already noted in the rfc. The parser in MDB2 works quite 
> reliably (I do not remember having much of any tickets), though I am not 
> a parser expert, so it could probably be implemented more efficiently.

Right, the PDO parser is rather basic. But no parser on a global level 
will ever fly.

SQL dialects differ from vendor to vendor. PDO must be able to push down 
the parsing task to the drivers. Only a driver can contain a proper 
lexer which is aware of its vendor specific SQL dialect.

Ulf