Last modified: 2012-08-04 20:48:42 UTC
I'm aware this regression is a result of the massive refactoring I and others have done for new-installer.
However, I need help from the postgres guys on moving DatabasePostgres::initial_setup() to the new-installer format (using callbacks similar to MysqlInstaller's setupUser). As best I can tell, this function does a few major things (and is called twice):
* Uses the superuser to create the less-privileged user that will access the database (this should copy MySQL's setupUser, although maybe at a different stage)
* Creates the database/schema and assigns the user (PostgresInstaller::setupDatabase() should be updated to include this)
* Sets up ts2 if needed (am I correct in remembering this is old and probably won't be needed much longer?)
* Setup Plpgsql if needed
* A few other minor tweaks (date format, timezone, etc)
These steps should be split out into functions in PostgresInstaller and added as callbacks to the correct stops in the install steps.
I didn't assign this to anyone, but this should be considered a blocker to the 1.17 release. CC'd Postgres guys and Mark H.
If you have specific "How do I do <foo>" questions I'd be more then willing to answer. I'd just rather not have to trace the myriad of function calls and new templating thats done.
That myriad of function calls is way clearer than the bowl of mush sitting in DatabasePostgres.
Suit yourself, I suppose. Needs review: r79828.
Changing dependency from bug 26611 to bug 26676. We don't need to fix this for deployment, but we do need to fix this before releasing the tarball
One problem is that DatabaseBase::selectDB() does not work for SQLite or PostgreSQL, so it should not be used in DBMS-independent code. In particular, needsUpgrade() is broken because it depends on selectDB() returning false if the database does not exist. I think PostgresqlInstaller should check for the existence of the database by attempting to connect to it with the administrative credentials, and checking the resulting error message for "FATAL: database "..." does not exist".
There's no guarantee that the administrative user will be able to connect to the template1 database, or any other specific database, so you can't use the pg_database catalog. If the database doesn't exist, I think it's fair to assume that you need to be able to connect to the "postgres" administrative database in order to create one.
The old installer relied on creation of a special user to ensure that the session settings were correct:
$SQL = "ALTER USER $safeuser SET timezone = 'GMT'";
$SQL = "ALTER USER $safeuser SET datestyle = 'ISO, YMD'";
This is missing from the new installer, which is good, but DatabasePostgres::open() should make sure the correct settings are set in the session.
Dropping support for full text search before PostgreSQL 8.3 (released 2008) would allow the setup code to be substantially simpler. The "schema for tsearch2" ($wgDBts2schema) setting could be dropped, currently it does nothing in PostgreSQL 8.3 or later. SearchPostgres.php would be slightly simpler.
See trunk as of r82674.
All of the $wgDBuser-specific settings have been cleaned up and are taken care of in open() and the pre-8.3 compat stuff has been dropped. I implemented a form of selectDB() (which works how you'd expect really) which resolves the upgrade issue.
Haven't handled the "admin user might not be able to use pg_catalog, much less template1" case yet.
I've got the installer in a working form now, although I've not tested any corner cases or given it extensive testing. If someone does find something, please open a new bug of course, and cc me.
closing per last comment