From:	Lukas Kahwe Smith	Date:	Wed May  7 07:13:39 2008
Subject:	Re: [PDO] PDO version 1 improvements

On 07.05.2008, at 15:01, Ulf Wendel wrote:

> 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.

Like I said, neither PostgreSQL nor Oracle support the "?" syntax. So  
at the very least rewriting to their relevant format needed to be  
supported.

> 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.

Well lets say that I also have trouble figuring out why a common DSN  
syntax was too much etc. Lets just say that most of the decisions were  
made by a single person and while that in theory can help in  
consistency, it probably does not work well for the mess that we have  
with different RDBMS following their own little standards.

> 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.

Right, people should be aware of this. If you use the native format  
for the given driver, then no rewriting will/should (should in this  
case probably does not work since the PDO parser ignores quotes around  
things that look like placeholders) take place.

> 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.

Well, JDBC does a lot of good things, but its not the gold standard  
either. Alot of the meta api's are nicely layed out, but also do not  
work in practice.

Anyways, removing this is too late, but maybe a switch to disable it  
would be in order?

regards,
Lukas