search_path vs extensions - Mailing list pgsql-hackers

Hi,
 Preliminary note: I'm using the term "extension" as if it's what we already agree to call them, feel free to ignore
thisand 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
isa 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
heavilyusing 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
requiredto 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
usingthe same SQL object name, so we'd need a way for extension authors to share a catalog of free names, like
internallywe 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_pathexplicitly.
 
Not good: Breaking existing application code by adding an implicit schema in an existing database is damn too easy. And
howto 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
whileapplication 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