The native handler currently does not support importing static data through the install tool or EM, the import will be incomplete in most cases.
Currently altering an existing column is not supported, as the underlying ADOdb library needs a full table description to do that, as on PostgreSQL you need to drop and recreate a table to change it's type (this has changed in PostgreSQL 8, but ADOdb doesn't support this yet).
Tests have shown you need to
enable ANSI quotes (SET QUOTED_IDENTIFIER ON)
set the max text length in php.ini to a value higher than the default of 4kB ; Valid range 0 - 2147483647. Default = 4096. mssql.textlimit = 5000000 ; Valid range 0 - 2147483647. Default = 4096. mssql.textsize = 5000000
Problems with persistent connectiosn were reported, so if you run into trouble, disable them in php.ini
More problems will arise, depending on the setup details. Further fixes and documentation is being worked on.
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. You have to use common sense and your DB background knowledge to move around those issues.
On some databases you might even see keys that should be dropped or created, most of the time this is bogus, too.
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.
If you have imported data into a table that is not running on MySQL, you may see error messages when inserting a new record (see e.g. bug #2106 on http://bugs.typo3.org/). This can be avoided by setting the sequence start to a number higher then the highest ID already in use in all the tables for that handler. See above for the configuration syntax.
Oracle for example has a restriction on table and field names, they can only be 30 bytes long. Some fields, especially of extensions adding fields to existing tables may violate that restriction. A way to work around this is to configure a field name mapping for those long names onto a shorter one before creating them (through the EM or install tool).
