Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
> I have some plans that we will be discussing later in the new dev cycle
> and that would impact such a method if we're to follow them. To better
> solve both the per-system (not even cluster) and per-database extension
> versions and the inline/os-packaged extension discrepancy, I'm thinking
> that we should move the extension support files from their shared OS
> location to a per-database location at CREATE EXTENSION time.
As a packager, I can say that moving shared libraries in such a way is
an absolute nonstarter, as in don't even bother to propose it because it
is not going to happen. Putting shared libraries into a
postgres-writable directory will be seen (correctly) as a security hole
of the first magnitude, not to mention that in many systems it'd require
root privilege anyway to adjust the dynamic linker's search path. You
could possibly make per-database copies of the control and script files,
but I don't see much point in that if you can't similarly
version-control the shared libraries.
I think we're better off sticking to the assumption that the files
constituting an extension are read-only so far as the database server is
concerned.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
