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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
