* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> My opinion is that a pg_extension schema with a proper and well
> documented set of search_path properties would be good to have. A way to
> rename it per-database doesn't strike me as that useful as long as we
> have ALTER EXTENSION … SET SCHEMA …
While having one place to put everything sounds great, it doesn't do a
whole lot of good if you consider conflicts- either because you want
multiple versions available or because there just happens to be some
overlap in function names (or similar). There are also extensions which
have more than just functions in them but also tables, which increases
the chances of a conflict happening. Having the extension authors end
up having to prefix everything with the name of the extension to avoid
conflicts would certainly be worse than actually using schemas.
Again, in PG, there's a lot more control which the database admin has
and, imv, DBAs are going to be able to manage the extensions if they're
given the right tools. Saying "dump everything in one place because
that's the only place we can be sure all users will look at" just
doesn't fit. There also isn't one central authority which deals with
how extension components are named, unlike with package-based systems
where Debian or Red Hat or someone deals with those issues. Lastly,
afaik, we don't have any 'divert' or 'alternatives' type of system for
dealing with legitimate conflicts when they happen (and they will..).
Basically, there's a lot of infrastructure that goes into making "put
everything in /usr/bin" work and we haven't got any of it while we also
don't have the problem that is individual user shells with unique
.profile/.bashrc/.tcshrc files that set PATH variables.
> The current default schema where to install extensions being "public",
> almost anything we do on that front will be an improvement.
Indeed.. I've never liked that.
Thanks,
Stephen