Re: pg_upgrade libraries check
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade libraries check |
Дата | |
Msg-id | 7462.1338222618@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade libraries check (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: pg_upgrade libraries check
|
Список | pgsql-hackers |
Dimitri Fontaine <dimitri@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
В списке pgsql-hackers по дате отправления: