Last modified: 2012-08-04 20:48:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 15816 - Add a switch for SETting the search_path (Postgres)
Add a switch for SETting the search_path (Postgres)
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: postgres
  Show dependency treegraph
Reported: 2008-10-03 10:13 UTC by hansm
Modified: 2012-08-04 20:48 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description hansm 2008-10-03 10:13:25 UTC
I would appreciate to see a switch in DafaultSettings.php that prevents 
class DatabasePostgres from SETting the search_path in the open() method.

If DatabasePostgres sets the search_path by its own ideas, there is no way for extensions to overlay its own schemas except explicitly referring to them. Anyway, I think setting the search_path for a DB user is the task of the DB admin, not of the mediawiki software.
Comment 1 Greg Sabino Mullane 2009-03-12 15:37:16 UTC
We're evaluating the whole way we do schemas in MediaWiki, but it's unlikely that we'd add something like this beforehand, as it could be a dangerous footgun. What's wrong with calling the schema explicitly if you are using a custom one, as I presume the extension is doing?
Comment 2 hansm 2009-04-09 15:23:49 UTC
What we do is to hold mwuser in an extra schema (named "zsamm") used by several wikis. The search_path for a wiki DB user is something like this: zsamm, de, public or zsamm, it, public. Thus, the mwuser table of the wiki schemas is hidden by the mwuser table in schema zsamm
This way, we can be sure to have the same user accounts for all of our wikis. And it works fine. Except when doing a version upgrade, because the upgrade script explicitley insists on ALTERing the mwuser table in the wiki schemas instead of using the search_path set to the wikiadmin ROLE.

Actually, I don't see why using the wikiadmin ROLE's search_path should be dangerous. It is an extra db user specially for maintenance scripts. So why disturbing a working configuration?
Comment 3 hansm 2009-04-09 15:37:08 UTC
Oh, excuse me, this was actually not the exact answer to your question. Let me give you some more explanations:

We have many extensions istalled that use their own DB tables. Some of them must be accessable for all of our wikis, others are wiki specific. In order not to mix up the original MediaWiki tables with tables used by extensions, we keep them in different schemas. We use PostgerSQL's schema mechanism to make every wiki's db user see the correct tables to use.

Let me give you an example: We have done several text imports from external sources. In order to guarranty proper source work and author attribution, we maintain a DB table for source works and one for authors. Both tables are used by all of our wikis simultanously. Therefore, we have prepended the corresponding schema to the MW standard search_path.
Comment 4 Marcin Cieślak 2012-03-09 17:36:26 UTC
Fixed in r113487

 We try to avoid touching search_path at all unless
 really necessary. Even in this case we append MediaWiki
 core schema to the front of the list.

 * No longer add $wgDBmwschema to PostgreSQL role search_path
 in the installer. This is no longer necessary as
 setting schema on connect should ReallyWorkNow(tm).

 * Get rid as much as possible of $wgDBmwschema and
 bring us one step closer to fix bug 16794 (wgSharedDB

 For further improvements to schema handling (bug 11136, bug 16794) we should   
 discuss how actually we are going to find out which objects (not only tables
 but also constraints, keys, etc. etc.) belong to which schema.

DatabasePostgres::getCoreSchema() should ideally be replaced and its callers 
adjusted with something that knows what should be were. Ideas how we can design
this with sane configuration (extension choices should be configurable in LocalSettings.php as well!) and without breaking constraints are welcome.

Closing this one, further discussion can continue in bug 16794 if needed.

Note You need to log in before you can comment on or make changes to this bug.