From: Operating system: all PHP version: Irrelevant Package: PDO related Bug Type: Bug Bug description:pdo_pgsql's PDO::exec() returns the number of SELECTed rows on postgresql >= 9.
Description: ------------ After executing a SELECT statement, PDO::exec() -using the pdo_pgsql driver and running against a PostgreSQL server older than 9.0- will always returns 0, as does the pdo_mysql and pdo_sqlite drivers. ie. this is the exepected behaviour (though to be precise, the PDO::exec() documentation stipulate : "PDO::exec() does not return results from a SELECT statement."). But when executed against a PostgreSQL >= 9.0 server, this very same php client and select statement will return the number of selected rows. This is due to a server side change in how PostgreSQL servers answers to libpqs's PQcmdTuples() commands (PQcmdTuples() being used as the PDO::exec() return value, via pdo_pgsql pgsql_handle_doer() function). This server-side change is visible by comparing this command's documentation for different PostgreSQL versions : http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC- SELECT-INFO http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC- SELECT-INFO See also the bug in pg_affected_rows https://bugs.php.net/bug.php?id=61266 I just reported. The attached patch does check whether the PDO::exec() param was a (successful) DML statement before using PQcmdTuples() to return the number of affected rows. Also attached, a test script for PHP's unit test infrastructure. Test script: --------------- // Bugs on PostgreSQL >= 9.0 server (but ok on previous versions) $dbh = new PDO("pgsql:dbname=postgres ;host=localhost", 'postgres'); var_dump($dbh->exec("SELECT * from generate_series(1, 42);")); Expected result: ---------------- int(0) Actual result: -------------- int(42) -- Edit bug report at https://bugs.php.net/bug.php?id=61267&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61267&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61267&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61267&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61267&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61267&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61267&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61267&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61267&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61267&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61267&r=support Expected behavior: https://bugs.php.net/fix.php?id=61267&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61267&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61267&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61267&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61267&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=61267&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61267&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61267&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61267&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61267&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61267&r=mysqlcfg
