On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
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.
I like this, although I'd want to be able, as a user, to override that
default and tell an extension to install in some other schema. That
would allow me to immediately overcome conflicts, and to organize my
extensions if I want, rather than throw them all in one place.
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)
I don't follow this at all. How to the three components effect
behavior? And what does this mean for where extensions are installed
in schemas?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
