Is not installable when using PostgreSQL as a database

Ok, so it was somewhat harder than what I expected! :-) Anyway, here is the patch - And a brief explanation. It is a bit invasive, but I think it's for the better overall. And, of course, warning precedes explanation: I am not a PHP coder, and I think it shows. I'm barely familiar with its basics, so I'm sure there are better ways of doing many things (I'm specially bothered by my repeated calls to db_data_types();).
I started by copying your declarations and fixing them, but that'd lead to maintenance hell - I think it's a real bad idea to repeat the DB declarations, as it would become impossible for future maintenance to keep both sets synchronized. I tried, then, to just replace whatever peculiarities I found with calls to either a function or an interpolated variable to make it work with a single code base.
MySQL is peculiar, as it hugely deviates from the SQL standards - The most invasive change I did (which makes following the diff a tough task) is to remove all the ` quoting around field names - MySQL is the only RDBMS which uses this nomenclature. I dropped all the backticks. MySQL does not complain, and PostgreSQL is way happier.
I added a couple of commodity functions at the end of the file: They all decide their behaviour based on $GLOBALS['db_type']. Begin with db_data_types(): It just creates an array of the data types (and other declarations used verbatim at table creation time). int(10) and int(11) become integer in Postgres; intyint1 and intyint4 become smallint, and int(11) auto_increment becomes serial; I also added here the indications to make the tables UTF8 (and MyISAM), as they are not needed in Postgres (you declare the character set per database, not per table).
Maybe this function should really chicken out if called from anything besides the supported RDBMSs? I'd like to, but as I said, this is the first time I write anything that touches the Drupal API. And it shows, I think.
There are five other functions, self-explanatory IMHO. They also don't do any work themselves, just hand back the right strings to be passed as SQL snippets. enable_keys_sql($table) and disable_keys_sql($table) are meaningless for Postgres, so they don't even both trying; add_key($table, $key_name, $flds) and add_ft_key($table, $key_name, $flds)create the key in MySQL or the index in PostgreSQL (again, fulltext means nothing to Postgres); alter_column_sql($table, $column, $new_type) adds a column to an existing table.
Besides this, my last change was not to use the multi-row inserts anymore, as they are only supported in MySQL. Whenever I found something like db_query("INSERT INTO table (col1,col2, col3) VALUES ($so, $me, $thing), ($some, $more, $stuff);"), I replaced it for foreach (array("($so, $me, $thing)", "($some, $more, $stuff)") as $item) { db_query("INSERT INTO table (col1, col2, col3) VALUES $item;"); }
As for the code quality: It works. I tested installing, removing and uninstalling the module several times from some Drupal sites I have both with MySQL and PostgreSQL, and it worked fine. There is still a hiccup somewhere, I think it is related to PostgreSQL executing nothing when you called disable/enable keys - I'll dig into it as soon as possible, but all the tables/fields get created, and the data gets loaded correctly. Oh! And I didn't support the updates number 15 and 16, as adding/dropping a primary key are completely different operations and I didn't find a way to represent them yet. If you think this is important (I don't think so - after all, your module has not yet supported PostgreSQL so far!), I'll dig into it.
So... Feel free to laugh at my code. But please, try to incorporate it into yours! ;-)
thanks a lot,

Ok, so this really-trivial patch to my patch fixes the remaining errors in Postgres. Executing a SELECT true; is more correct than just executing nothing.

Heh - Thanks a lot. Still, I do expect -as 4.7 still lives on- 5.x to go on for a long time. There is too much installed base. I'm a bit worried about modules being slowly phased out... But as it is today, everything is 5.x-compatible... And almost nothing is ready for 6.x
I also didn't expect it to be so much work - but hey, thank you for the module! My work is but a tiny fraction of it.