Description: ------------ alterDatabaseIndexes() fails to add a UNIQUE attribute to an existing non-unique index. This happens because it makes the false assumption that if the new index definition has the 'unique' attribute (making it a constraint in MDB2 Terms), the existing index would we a constraint too and calls dropConstraint() even when dropIndex() would be the correct choice. The attached patch checks whether the existing index (if present) is actually a constraint and takes the appropriate action on it. Test script: --------------- Existing index was created with this definition: <index> <name>foo_bar</name> <field> <name>bar</name> </field> </index> New definition is: <index> <name>foo_bar</name> <unique>true</unique> <field> <name>bar</name> </field> </index> Expected result: ---------------- updateDatabase() turns existing index foo_bar_idx into a UNIQUE constraint. Actual result: -------------- DBMS (tested with PostgreSQL) aborts with an error because ALTER TABLE ... DROP CONSTRAINT is called on a nonexistent constraint.

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.