php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #44861 scrollable cursor don't work with pgsql
Submitted: 2008-04-29 16:13 UTC Modified: 2009-03-28 19:09 UTC
Votes:4
Avg. Score:4.8 ± 0.4
Reproduced:4 of 4 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: php at benjaminschulz dot com Assigned: mbeccati (profile)
Status: Closed Package: PDO related
PHP Version: 5.3CVS-2008-04-29 (CVS) OS: Irrelevant
Private report: No CVE-ID: None
View Developer Edit
 [2008-04-29 16:13 UTC] php at benjaminschulz dot com 
Description:
------------
I don't see how to use scrollable cursors with pdo_pgsql

Reproduce code:
---------------
$db = new Pdo("pgsql:...");
$db->setAttribute(Pdo::ATTR_ERRMODE, Pdo::ERRMODE_EXCEPTION);
$res = $db->prepare("SELECT 'row1' UNION SELECT 'row2' UNION SELECT 'row3' UNION SELECT 'row4'", array(PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL));
$res->execute();
var_dump($res->fetch());
// $res->fetch(Pdo::FETCH_NUM, PDO::FETCH_ORI_ABS, 2) won't throw an exception but return false

Expected result:
----------------
array('row1')

Actual result:
--------------
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[34000]: Invalid cursor name: 7 ERROR: cursor "pdo_pgsql_cursor_00d78a0c" does not exist' in ...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-12-12 11:36 UTC] denis at edistar dot com 
Same problem also in PHP 5.2.6.

I think this is a very serious bug.
 [2009-01-15 22:30 UTC] andrew at rook dot ca 
Same problem.
PHP 5.2.8 on Fedora 8 (2.6.21.7-5.fc8xen) && PostgreSQL 8.2.11
 [2009-02-04 00:43 UTC] matteo at beccati dot com 
Here's the patch, including a phpt file:

http://www.beccati.com/misc/pdo_pgsql_bug44861_php_5.3.patch

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.
 [2009-03-28 19:09 UTC] mbeccati@php.net 
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
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Oct 29 20:00:01 2025 UTC