go to bug id or search bugs for
I don't see how to use scrollable cursors with pdo_pgsql
$db = new Pdo("pgsql:...");
$res = $db->prepare("SELECT 'row1' UNION SELECT 'row2' UNION SELECT 'row3' UNION SELECT 'row4'", array(PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL));
// $res->fetch(Pdo::FETCH_NUM, PDO::FETCH_ORI_ABS, 2) won't throw an exception but return false
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE: Invalid cursor name: 7 ERROR: cursor "pdo_pgsql_cursor_00d78a0c" does not exist' in ...
Add a Patch
Add a Pull Request
Same problem also in PHP 5.2.6.
I think this is a very serious bug.
PHP 5.2.8 on Fedora 8 (184.108.40.206-5.fc8xen) && PostgreSQL 8.2.11
Here's the patch, including a phpt file:
A bit of explanations... I've changed the ordering when executing the query so that if a cursor is needed, it's created before any preparation happens.
The cursor is now declared as SCROLL-able and WITH HOLD to ensure it can be used even outside transactions. I was previously trying to avoid WITH HOLD and enforce requirement for a transaction, but things were going very bad when the destructor was called after the transaction was closed, which is a common situation when calling commit() without previusly unsetting the statement variable.
One thing I'm not really sure about is the behaviour of ORI_ABS and
ORI_REL: ORI_ABS will work for offsets >= 1, while ORI_REL can work with negative numbers as well. I'm sorry, but it's impossible for me to guess how they should work just by reading the pdo_oci code or the Oracle documentation of OCIStmtFetch2.
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.