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

On Sat, Mar 27, 2010 at 4:05 PM, Matteo Beccati <[email protected]> wrote:
> Hi Stanley,
>
> Thanks for that. Again I have very limited time for PHP/PDO. I've reviewed
> your updated 5.3 patch and couldn't see anything wrong with it.
>
>
> On 27/03/2010 02:15, Stanley Sufficool wrote:
>>
>> http://bugs.php.net/bug.php?id=50755&edit=2
>>
>> Patch revised:
>> ------------------------------------------------
>> 1. Reverted driver always registering as dblib.
>>
>> Question: Should the user really have to know the library the extension
>> was compiled against? Seems like we should settle on a constant
>> registration since you really can't mix and match.
>
> It might be useful in case the libraries have slightly different behaviours.
> The fact that I've never used any of them doesn't help me to understand why
> this behaviour was implemented in the first place.
>
> Anyway, this decision does not belong to this bug report.
>
>> 2. Reverted whitespace modifications. Removed spurrious comments.
>> Reverted DBSETOPT -->  dbsetopt.
>>
>> 3. Reverted SYB* -->  SQL* define deletions. These are required for
>> compile against the depreciated MS DBLIB.
>>
>> 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.
>
> I was under the impression that it was something added by your first patch.
> In any case the patch needs to be backwards compatible, otherwise the it
> can't go in PHP 5.3.
>

"This extension is experimental" says it all. In my not so humble
opinion, the last implementation of magically naming columns was
wrong. If I have a query: "select 1+1, compute1 from some_table", then
this gets broken for associative array reference to my second column
by some undocumented magic column naming.

If I have to reproduce this behavior, I'm back to allocating column
attribute structures outside of the library and praying that my
assumptions about future library column naming behavior is correct.

>
>> Some unrelated/unmentioned "fixes"
>> ------------------------------------------------
>> Allow multiple rowsets with varying column definitions. This was
>> implemented incorrectly.
>> Include the recent update to SQLMONEY formatting.
>>
>> Tested against SQL Server 2008 Express, PHP-5.3 svn-296442, FreeTDS
>> 0.64, Linux 2.6.30 - i686&  amd64
>
> Are there any new tests that could be written to ensure that the extension
> still works as expected and/or to test the new functionality?
>

Prerequisites to testing this are a fully running Sybase or SQL
Server. I have the scripts I used and will include them ASAP. They
tested connection, query, statement re-use, traversal, binding and
multiple result sets.

>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/
>
> --
> PDO Working Group Mailing List (http://pdo.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>