On 10/25/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > From time to time people have raised the idea of a CPAN-like mechanism > for downloading, building and installing extensions and the like (types, > functions, sample dbs, anything not requiring Postgres itself to be > rebuilt), and I have been thinking on this for the last few days. What > sort of requirements would people have of such a mechanism? How do > people envision it working?
>From a user's point of view, it would work like this : $ pgsql-pkg list Installed packages : ------------------------------ pgpool-II v.1.2.1 plR v.220.127.116.11 $ cd /usr/src/pgsql-packages/ $ cvs update $ cd languages/plR $ make upgrade $ cd ../../compatibility/orafce $ make install $ pgsql-pkg list Installed packages : ------------------------------ pgpool-II v.1.2.1 plR v.18.104.22.168 orafce v.2.1.2 A starting point worth considering could be pkgsrc , the packaging system used by NetBSD ( http://www.netbsd.org/docs/software/packages.html ) . Pkgsrc is not limited to NetBSD : it works on other OS'es as well (Linux, *BSD, Solaris, HP-UX, ... ) . The pkgsrc is based on a directory tree organized in categories. For each package there is a directory that contains the Makefile, the description, and sometimes patches . The user can do : make build , make install , make upgrade , etc. The sources are downloaded from the server where the project is originally hosted : NetBSD is not duplicating the source archives on their server. If necessary, the build system can apply patches before compiling the package. This allows the NetBSD folks to adapt the package without requiring modifications to the original sources So, the mechanism for PostgreSQL extensions could work this way : (A) The source tree would be an adapted version of pkgsrc : - the extensions are organized into directories (based on categories) - each extension would be a directory that basically contains a Makefile that contains enough information for downloading the source tarball, optionally apply patches, and install the package(extension). - probably it will be necessary to create a separate source tree for each PostgreSQL version , so that the build system wouldn't be cluttered with keeping information about which package version is compatible with which PostgreSQL version. - with such a system it is possible to include an extension even if the maintainer of that particular project doesn't modify anything for making it compatible with the extensions system . (B) Some extensions are only sql scripts that install new objects into a database, while others could also contain binaries, libraries, or maybe other stuff as well. Therefore, the installation probably has to be two-step : step 1 : 'make install' would copy the files in a new subdirectory called "extensions" : /usr/local/pgsql/extensions/bin /usr/local/pgsql/extensions/lib /usr/local/pgsql/extensions/install_scripts /usr/local/pgsql/extensions/remove_scripts /usr/local/pgsql/extensions/examples and add the extension to the list of 'installed extensions'. step 2 : for activating the extension inside a particular database the user would execute the extension's install_script. The first step is installing the extension at the database cluster level , while the second step is installing the extension inside a particular database. I think that this distinction is an important one : the user will need full control in installing the extensions only in the databases where she/he wants to. (C) It would be nice to have a table containing information about the extensions currently installed . Cheers, Adrian Maier ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate