search_path vs extensions

Hi,

Preliminary note: I'm using the term "extension" as if it's what we
already agree to call them, feel free to ignore this and use whatever
term you see fit. We'll have the naming issue tackled, please not now
though.

Following-up to discussions we had at the Developer Meeting and
subsequent pub events, I'd like us to agree upon the relations of
extensions and search_path. We basically have to choose one of those:

Proposal: do nothing
What's good about it:
it's already there, folks!
What's not good about it:
Users are alone on deciding where to put what, and the system won't
help them: either public is a complete mess, or they have to manually
care about search_path for their extensions and their own application
needs. Installations where DBA and application folks are separate
teams will suffer, ones where the application is heavily using schemas
will suffer too.

Proposal: pg_extension, a new dedicated system schema for extensions
Good:
It's easy to see SQL objects (\df) of extensions (think contribs) you
installed, and as extension developpers are required to use it, you
don't have to care about it any more.

As you have only one namespace for everyone, the collisions are
detected early.
Not good:
As you have only one namespace for everyone, collisions prevent users
from installing several extensions using the same SQL object name, so
we'd need a way for extension authors to share a catalog of free
names, like internally we do for systems OIDs in the bootstrap,
IIUC. But in a distributed fashion.

We would have to add ways for the user to see which extension which
object belongs to, so you'd have extension | schema | object_name
columns in all \dX things, e.g.

Proposal: allow user schema to behave the same as pg_catalog
Good:
Tell the system your schema is implicit and be done with it, object
searching won't need users to manage search_path explicitly.
Not good:
Breaking existing application code by adding an implicit schema in an
existing database is damn too easy. And how to choose if the implicit
schemas are to be searched in before or after the search_path?

Proposal: Separate search_path into components: pre_search_path,
search_path, post_search_path
Good:
This allows to easily separate who changes what: typically DBAs will
edit pre and post search_path components while application will care
about search_path the same way as now.
Not good:
2 new GUCs (but no new semantics, and defaults to empty)

My vote is to go with the pre/post search_path components proposal as
it's the one allowing the more flexibility, and we tend to value this a
lot around here.

Regards,
--
dim