Re: pg_upgrade libraries check
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Cc: Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-05-28T16:30:18Z
Lists: 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