I'm considering diving into the source to add support for using PostgreSQL as an alternative database for those who prefer using it (like myself.)

This would require a new module similar to the MySQL.php file and code that allows for one or the other to be loaded (so the bot doesn't die if MySQL isn't there, but PostgreSQL most certainly is.)

Okay, I've taken a cursory glance at the source for several .php files and I think your suggestion on IRC to encapsulate the "create table" calls in a separate function from "query" is probably best.  The reason I say this is... there are enough differences between MySQL and PostgreSQL to warrant it.  The easiest example to use is "auto_increment."  MySQL uses auto_increment to define a variable that automatically increases in value each time an insert is applied to the table.  PostgreSQL uses sequences instead.

I also want to encapsulate things like MYSQL_ASSOC into a variable, because the pgsql equivalent function uses PGSQL_ASSOC instead.

It's going to take some work to try to make the database functions transparent, but I think it will be worth it in the end (because it will make it easier for the next person to add support for their favorite SQL server!)

The default return type for postgres is PGSQL_BOTH.  I haven't looked at the php functions for mysql to see what the default is for it, but I assume it's the same.

I don't like assuming default behavior, because it can change at any time in future updates to php.  This would potentially cause problems.  Returning BOTH doubles the size of the return array, but not every mysql query is calling ASSOC.  I haven't looked to see if only the "create table" calls are not doing this, but I think (from memory) that some of the regular select queries were not calling ASSOC, and thus there is some mixed behavior in the bot already.  I could be wrong, though.

Either changing it to be consistently ASSOC or changing it to use a wrapper variable as part of the encapsulating "SQL" object would work.

Then I'll look at making ASSOC be the "default" for the query function in the generic SQL wrapper class when I add the create() function for creating tables.

I really do not see any good reason to keep using numeric indexes from the queries.

It would require a thorough rewrite of every function using the numeric version...
I guess this is the main reason why it isn't changed.

Feel free, if you create a patch file I'll most likely commit the changes to the SVN.

Changes to the trunk may create some conflicts, as I'm trying to get some work on the bot done the next days.

I'll hold off on this until a consensus is met.  Whatever the case, the "BOTH" or "ASSOC" needs encapsulation, because "MYSQL_BOTH" and "MYSQL_ASSOC" are for the mysql functions only.  The postgresql functions have their own "PGSQL_BOTH" and "PGSQL_ASSOC" and that is what should be used when the database is postgres instead of mysql.

You could make an abstract base class for database access, and then make MySQL and PostgreSQL and perhaps any further dababase we use.

This is what I've meant when I've said "encapsulated."

Then define abstract functions in the database class like get_assoc(), get_both(), get_number(), and the implementations return the valid MYSQL_ASSOC or PGSQL_ASSOC values as the database needs.

Yep... pretty much what I was planning.