Description: ------------ I posted a comment to the closed bug: http://pear.php.net/bugs/bug.php?id=10986 I'll open a new bug here because it doesn't seem to have been noticed. Is there a reason the statement name is being randomly generated? Even though the patch provided in the referenced bug report is more random, it could still potentially collide. The chances of a collision go way up if you're doing many thousands of queries in a row (something I have to do from time to time). Why not add a new member to the MDB2_Driver_pgsql class: var $prep_statement_counter = 1; and then increment the counter for each new prepared statement: $statement_name = sprintf($this->options['statement_format'], $this->phptype, $this->prep_statement_counter++); No more collisions, no matter how many queries you run!

There is a small problem with your suggestion: the counter is reset at each script invocation...

We really need to _fix_ this problem, not just minimize it. Your objection is only a problem if you have more than one database connection open at a time. The prepared statement names are reset in PostgreSQL each time you connect, at least in my experience. But if you still object to that idea, why not have the following strategy for naming prepared statements: "microtime(true) when script was invoked" . "-" . "counter" So you might have the following as statement names for one script invocation: 1184773707.2127-1 1184773707.2127-2 etc... and the following for another script invocation: 1184773707.2128-1 1184773707.2128-2 etc... Thus, each script invocation would have a unique microtime prefix, and you can add the counter on the end to make each statement name unique to that script. That should solve the problem of multiple invocations, and still have the benefit of a counter instead of a random name generator.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.