php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #63356 Add support for native php data types returned from Firebird PDO select queries
Submitted: 2012-10-25 08:11 UTC Modified: 2013-02-13 04:25 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:1 (25.0%)
Same OS:2 (50.0%)
From: james at kenjim dot com Assigned: mariuz
Status: Assigned Package: PDO related
PHP Version: 5.4Git-2012-10-25 (Git) OS: All
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2012-10-25 08:11 UTC] james at kenjim dot com
Description:
------------
The data returned from a $rs->fetch() should use native data types when applicable.  Currently all data is turned into strings.  Using native data types will not only provide a way for the user to easily check the data type.  It should also give a performance enhancement since everything does not need to be turned into a string.  Some other database adapters already provide this ability.

I have included a patch to add this functionality however I did have to modify /ext/pdo/pdo_stmt.c due to the way it was handling returning of zval's.  It was expecting a ***zval when it really should of been a **zval.  Due to this excessive pointer requirement any other pdo database driver that returns zval's will need to be fixed.  I included in my patch a possible fix for the mysqlng pdo driver since I believe this is the only driver that uses it.  I say possible fix because I have not tested the mysqlng support part of it.  The patch also includes my patch for Bug #61183 - Firebird PDO memory corruption.  It should also fix Bug #60052 - Integer returned as a 64bit integer on X64_86.  It also fixes the patch that was improperly applied in Bug #47415 - PDO_Firebird segfaults when passing lowercased column name to bindColumn().


Patches

Firebird_Native_Data_Types (last revision 2012-10-25 08:11 UTC) by james at kenjim dot com)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-11-23 13:24 UTC] mariuz@php.net
-Assigned To: +Assigned To: mariuz
 [2013-02-08 07:53 UTC] mariuz@php.net
Could you split the patch for each bug the ones that you mentioned at the end

Also i will ask about the patching of /ext/pdo/pdo_stmt.c , i'm not sure what is 
the right way so i better ask on the list first
 [2013-02-13 04:25 UTC] james at kenjim dot com
The problem with the ***zval is I could not figure out how to return such a data type without causing a memory leak.  The extra pointer to a pointer just seemed excessive and removing it solved my problem.

As for splitting the patches, a few of them depend on each other so there is no good way to split them without creating patches that do not work with each other.  The patch for bug #61183 has already been submitted there and is simple enough that it could be removed from my submitted patch here by hand.  Bug #60552 gets fixed because the majority of the time I'm using native data types so I can't exactly remove it from my native data type support patch.
As for Bug #47415 that patch was just improperly applied to the php source tree and ended up in the wrong switch statement.  I suppose that could be pulled out of this patch but I did also modify the PDO_PARAM_EVT_FETCH_POST case which the patch was embedded in.  I don't remember why I removed most of that PDO_PARAM_EVT_FETCH_POST switch statement.  I think it was because I couldn't figure out why it was ever needed or even run.  It's also possible it may have caused a crash but I don't recall it's been too long.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Thu Apr 17 09:02:29 2014 UTC