Re: modules - Mailing list pgsql-hackers

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 <rm_pg@cheapcomplexdevices.com> 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