Description: ------------ I am running PostgreSQL 8.0.8. I have a stored procedures which takes several arguments (9), inserts the data into one or more tables according to some rules, and then returns the value from a PostgreSQL sequence of one of the tables. I have this sp run several times in a foreach loop. On one particular run, it successfully executes the sp 10 times, but the return value from the 10th run, instead of being a result object, is simply the number 1. The query itself appears to have run successfully - the table has 10 new rows in it. On some data sets it runs just fine. There is only one data set where this behavior is exhibited and I am wholly unsure as to why. Below is a summary of the offending lines of code with the bad data. note: Data comes from flickr Test script: --------------- $sql = 'SELECT register_tile( ? , ? , ? , ? , ? , ? , ? , ? , ? );'; $register_tile_stmt = $pear_db->prepare($sql); //... $tile[0] = mt_rand(100000, 100000000); $tile[1] = 'Nautilus'; $tile[2] = "The chambered or pearly nautilus is a member of the cephalopod class of the mollusks. The nautilus is a "living fossil" whose close relatives date back 100's of millions of years into geologic history. The two living species of Nautilus live at great depths (~600 meters) within fore-reef habitats of the Indian and Pacific oceans. This one, sawed in half to show its chambers (used for regulating density), is from the waters of the Philippines."; $tile[3] = 117731641; $tile[4] = 'b084a38eaa'; $tile[5] = 39; $tile[6] = '32543267@N00'; $tile[7] = 'Attribution License'; $tile[8] = 'NULL'; $result =& $pear_db->execute($register_tile_stmt, array( $tile[0], $tile[1], $tile[2], $tile[3], $tile[4], $tile[5], $tile[6], $tile[7], $tile[8] )) if (PEAR::isError($result)) continue; if (!is_object($result)) echo $result; //this should never be run! $result->fetchInto($row); //... Expected result: ---------------- The above chunk of code *shouldn't* output anything. Actual result: -------------- Outputs '1';

updated summary to better reflect problem.

It seems like either the query is incorrectly interpreted as a manipulation query or its not recognized as a SELECT: if ($ismanip) { .. return DB_OK; } elseif (preg_match('/^\s*\(*\s*(SELECT|EXPLAIN|FETCH|SHOW)\s/si', $query)) { .. return $result; } else { .. return DB_OK; } Could you check what "$pear_db->affectedRows()" returns? Could you also paste the output of "var_dump($pear_db->last_query);" ?

I've whittled it down and figured out the root of the problem. When $tile[2] equals "y into g" (or just "word1 into word 2"), $pear_db->query() returns 1. This is most certainly a bug no?

Another limitation of DB::isManip(). I suggest you explore moving to MDB2 which superceeds DB. Marking as duplicate of: http://pear.php.net/bugs/bug.php?id=3895