Re: [PDO] Fwd: Bug #50755 [Opn]: PDO DBLIB Fails with OOM

On Sat, Mar 27, 2010 at 12:04 AM, Lester Caine <[email protected]> wrote:
> Stanley Sufficool wrote:
>>
>> 4. Removed automagic compute column naming (which was clobbering library
>> memory). Just return what the server returns including empty strings.
>> The user will need to alias in their sql query as "select 1+1 as
>> oneplusone" instead of just "select 1+1" magically returning
>> array('compute1'=>'2').
>>
>> Question: Who if anyone relies on this behavior? I don't see other
>> drivers doing this.
>
> That is a little more fundamental question ;)
> Since PDO is currently scoped only to abstract the data, then anything
> related to changes to the SQL should not be happening. So in theory if you
> switch the driver a simple SQL query should still work? There are many
> reasons why it will not work but that is not for PDO to address! So there
> should be nothing 'automagical' in any of the drivers unless it produces
> results that are SQL standard compliant across all drivers?

Yes, I don't think an abstraction layer should add anything to the
returned data unless it is done uniformly across all drivers.

More specifically, My question was, should a fetch() on "select 1+1,
'sometext' " return:
array(0=>2, 'compute1'=>2, 1=>'sometext', 'compute2'=>'sometext')
or
array(0=>2, ''=>'sometext', 1=>'sometext').

My preference being the latter since it is my own fault for not being
specific in my SQL column naming and that there is not real way to
ensure these columns are renamed consistently across all drivers.

>
> My own stand point is that PDO is still not user ready until it provides a
> little more REAL cross database compatibility, so something like this is not
> acceptable and must be addressed in the SQL initially provided.

PDO is at least a step in the right direction. We can add another
SQLParser layer on top of or in PDOStatement to provide complete SQL
abstraction for non-relational data (CSV, BerkDB, dbase, GDAL, etc...)
. However, this is more than likely re-inventing a lot of ODBC work
that has already been done.

Goal #1, get all the PDO basic functionality implemented across as
many drivers as possible and stabilize. Goal #2, extend PDO to allow
each driver implementation to support specific functionality of the
DBMS so that all of the database extension maintainers (mysql, pgsql,
mssql, oci8, sqlite, etc...)  can get on board with PDO without losing
functionality.

PDO needs to bring more people to the party. I'm starting to look
longingly at Java and JDBC.

So more comments needed, or can we commit this patch? Since this
extension is marked experimental, I think the behavior change should
be acceptable.

>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PDO Working Group Mailing List (http://pdo.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>