Think about version API compatibility.
Suppose you have a working database on server A which uses module foo
version 1.
Some time passes, you buy another server B and install postgres on it.
Meanwhile the module foo has evolved into version 2 which is cooler, but
has some minor API incompatibilities.
You dump the database on server A and reload it on server B. pg_dump
issues an INSTALL MODULE which installs foo version 2 on the new server.
Due to the "minor API incompatibilities", your database breaks.
It's really cool not to pollute the dumps (and the global namespace...)
with all the module functions, however implementing module functionality
can be tricky.
So don't forget about versions and possible incompatibilities ; also
versions means you might need an UPGRADE MODULE which does more than
uninstall + reinstall. Suppose a module has created some tables for its
use, these shouldn't be dumped when upgrading to a new version ; however
maybe the new version will want to add a column...
Think gentoo portage, for instance.
This excellent package system is a lot more evolved than the module
system needs to be, but having a look at the feature list would be a good
inspiration maybe.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
