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?

hansm wrote:

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?

hansm wrote:

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.

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 support).
  
  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.

Migrating from the old tracking task to a tag for PostgreSQL-related tasks.