I had some thoughts about similar issues when looking at what it would take to make pl/java yum-installable. The end goal was to be able to say e.g. yum install pljava; echo "create language pljava;" | psql mydb. Currently there's a non-trivial install process involving running an sql script and java class.
My idea was to have a createlang_init kind of function that could be called when installing a language to set up appropriate functions, tables etc. There would be a similar function to clean up when dropping the lang. On Thu, Apr 3, 2008 at 6:12 AM, Ron Mayer <[EMAIL PROTECTED]> wrote: > Agreed. Such a mechanism would only really apply for things > that are installed in the database. But from an end user's > point of view, installing functions, index types, languages, > data types, etc all see to fit the "pg_install postgis -d mydb", > "pg_install pl_ruby -d mydb", etc. pattern pretty well. > Well, there are a couple of major differences. Firstly cpan, gem etc are able to install all required dependencies themselves, at least where no native compilation is required, because they are basically their own platform. PG libs more or less require a build environment. Secondly, and more importantly, module installation for those environments happens once and is global; installation of native libs for pgsql is different to instllation in a database. What happens in the above scenario when the postgis libs are already installed? And what about cleanup? Also, it would seem that such an install process requires the server to be running - so much for packaging as RPMs/debs/win32 installer etc. I think a better solution would be to have a pg_install be a distribution mechanism capable of installing binaries / scripts / other resources, but have pgsql itself handle module installation into a particular database. I'm thinking a "CREATE MODULE foo;" kind of thing that would be capable of finding either a module install script or a foo_init() function in libfoo.so/foo.dll. Similarly for cleanup, so cleanup isn't dependent on pg_install lying around or the version that was install still being the latest when pg_install looks for an uninstall script. This would allow modules to be installed site-wide but optionally created / dropped from specific databases in a much saner manner, and standard pgsql permissions could apply to installation of modules. It would also allow creation of rpms etc that can be shipped by a distribution, and then enabled by the user by calling the appropriate command. >> Finally, setting up modules so they can be built for Windows, especially using MSVC, will probably be quite a challenge. >> > > Indeed. Seems ruby gems give you the option of installing a "ruby" > version or a "windows" version that I'm guessing has pre-compiled > object files. Yeah, setting up Cygwin to build postgres is a pain (or was when I last did so). If we're serious about setting up a central repository, we should consider having a virtualized windows machine capable of building binaries for the modules that people upload. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers