Whenever a database structure comparison is done, it is likely that differences are detected, that have no real background. The unsigned attribute used with integer fields in MySQL for instance has no equivalent in PostgreSQL. Thus if a change is suggested that would solely try to add this attribute, just ignore it. To make this easier the changes that are usually preselected in the install tool are not, when the DBAL extension is detected.

Similar “errors” will be detected for certain field types and probably keys/indexes. For the time being you have to use common sense and your DB background knowledge to move around those issues.

MySQL allows the user to change nearly everything at runtime, you can change field types, constraints, defaults and more on a field and MySQL handles data conversion and similar tasks transparently. This does work very differently with many other DB systems, some things do not work at all. Since we rely on existing abstraction libraries, we  are bound to what they offer. There may be cases in which it simply is impossible to do a needed change to the database automatically.

It is even problematic to add fields to existing tables, although this seems like a rather simple thing to do. But, alas, it is not.

It must be noted that e.g. the recent version 8.0 of PostgreSQL was a huge step forward in that direction, as it allows a lot more of those operations in an easy way, than earlier versions. So if you want to run TYPO3 on PostgreSQL, use version 8.0 or later, of possible.

The Advanced Query tool in the Full Search of the DB Check in the backend doesn't “speak DBAL” yet, so it won't work with anything but MySQL until this has been worked on.

Currently there are bugs when using DBAL with the „native“ handler type on MySQL. The alternative is to skip DBAL or use ADOdb to access the database.

Please use the bug tracker at http://bugs.typo3.org/ to submit any bugs you find in this extension (or near it) to the project tx_dbal.