Description: ------------ While porting an existing database schema to XML, I ran in to a problem with an - admittedly weird - table where an autoincrement field was defined, but another column was used as primary key. Forcing the autoincrement field to be primary key is documented behavior and makes sense. Unfortunately, this is enforced silently upon table creation with possible sideeffects instead of failing validation entirely. Test script: --------------- <field> <name>auto</name><type>integer</type> <notnull>true</notnull> <autoincrement>true</autoincrement> </field> <field> <name>other</name><type>integer</type> <notnull>true</notnull> </field> <index> <name>foo_other_primary</name> <primary>true</primary> <field><name>other</name></field> </index> <index> <name>foo_auto</name> <unique>true</unique> <field><name>auto</name></field> </index> Expected result: ---------------- XML Schema validation should abort with an error because the auto column is not defined as primary key. Actual result: -------------- The auto column is silently forced to be primary key, leaving us with an additional (now useless) unique index over the auto column and NO CONSTRAINT AT ALL for the other column. Ouch.

Hello Holger, I am checking this. Regards, Igor.

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.