More information about connections:
If you don't use the standard 5432 port for PgSQL, the script will refuse to connect.

To quickly bypass this problem, change the connection variables like this:

In the host, place the classical pgsql connection string (host=... port=... dbname=... user=... password=...)

Then, in the core/database_api.php file, find the db_connect function and change is call to "Connect($p_hostname, $p_username, $p_password, $g_database_name );" into "Connect($p_hostname);"

I know this is dirty, but if you're in a hurry, it works...

Bug fix: I didn't notice that when a user preference is unchecked, the empty string is send as an update for the integer, which is unable for PostgreSQL, so I make a fix in the second attachement file converting all the guilty integer fields into varchar fields.

You should use INT's not varchar(3).

Latest CVS version of mantis fixes the user_pref's to supply 0 for any instead of 'any'

This is for exactly the same reason you hit - mysql 'supports' any meaning 0.
mssql/pgsql are rather more sensible in only allowing integer's into INT column's, not strings.

Paul

regarding, the other point:

What's wrong with just setting in the config:
$g_hostname = "host=... port=... dbname=... user=... password=...";

Paul

I didn't choose CVS version cause the tracker must be use in production and my chief does only accept official release for this.

Anyway, 'any' values are not the only "false" values accept by mysql. mysql also accept empty string as an integer, what is done when you uncheck some user preference. PostgreSQL don't. So, until mantis doesn't convert empty string to default integer value, postgresql will refuse to update the mantis_user_pref_table.

For the second point, if you simply update the g_hostname string without chaging signature of the Connect function, the others argument seems to be taken in account and it result in the fact that the connection failed. I try this first, but it didn't work until I update the call to the function.

regards,
Olivier

Both the mssql.sql and pgsql.sql are out of date.

For the next release, i'm hoping to get an adodb data dict schema defined which will generate the mssql/pgsql tables. As adodb's datadict is generic, this means that we won't have to keep multiple schema files in check. It also means that it may be possible to use other db's that are supported by adodb's datadict with mantis.

If this functionality goes into the next release, the mssql/pgsql.sql files will become redundant.

Notes:

1. The aim is to have the generated adodb schema match the existing schema's created by the sql files.
2. Once the code is added to CVS, it would be interesting to get some feedback, or any differences in the schema to the existing databases you are using

I'm going to use issue 0005289 to track the datadict stuff, so closing this issue now.