On Mon, Jan 23, 2012 at 8:17 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Robert Haas <robertmh...@gmail.com> writes: >>> Ok, but then, what about .so files? Wouldn't it make sense to be able >>> to ship also the executable modules needed, and if not, why not? > > Now you can dump/restore any extension fully, and we can even ship any > extension in the WAL stream (a new message is needed though).
Things are still a bit ugly in the more complex cases: consider PostGIS's linkage against libproj and other libraries. In order to cover all cases, I feel that what I need is an optional hook (for the same of argument, let's say it's another "command" type hook, e.g. "archive_command") to be executed when extension (un)installation is occurs on a primary or is replayed on a standby whereby I can acquire the necessary dependencies for an extension or signal some kind of error (as to exactly how that interfaces with the server is delicate, should one want to supply good error messages to the user). I think that hook could be useful for a number of reasons: * Extension distribution (as long as we're downloading dependent libraries, why not get the extension too?) * Extension distribution on standbys, too -- by much the same mechanism * Extension whitelisting for non-superusers (are you allowed/can you even have that extension?) And, more to the point, if one wants to make replication and extensions work nicely together, I don't really see an option outside such a hook other than insisting on a form of packaging whereby all dependencies are declared to Postgres and Postgres becomes the dependency management system for all dependent binary assets. That could lead to a more cohesive system, but is also a pretty hefty burden, both on this project and others. But getting back to in-line extensions: I think it makes sense to dump all extensions in their in-line representation even if in some situations carrying a copy of the extension in the backup is not strictly necessary. The only bloat is including the literal sourcetext of the extension in the dump. With a extension-installation hook, the literal version of the extension could be supplied but ignored if an side-channel mechanism for getting the extension makes sense. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers