Re: Database owner installable modules patch - Mailing list pgsql-hackers

From Tom Dunstan
Subject Re: Database owner installable modules patch
Date
Msg-id ca33c0a30804070346m256d7c55na0832ac1d86a597f@mail.gmail.com
Whole thread Raw
In response to Re: Database owner installable modules patch  ("Tom Dunstan" <pgsql@tomd.cc>)
Responses Re: [PATCHES] Database owner installable modules patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Sorry to keep replying to myself, but part of the point of doing a
patch was to force myself (and whoever else is interested to examine
stuff that comes up...

On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <pgsql@tomd.cc> wrote:
>  None of that suggests that an uninstaller script would be needed if we
>  understood the deps well enough, but only allowing creates for
>  installs seems a bit restrictive.

OK, I found an example that does NOT fit the "just drop all
dependencies" scenario, but that I would still like to support. I just
had a look at the postgis pl/java support, and its install does stuff
like "SELECT sqlj.install_jar('file://${PWD}/postgis_pljava.jar',
'postgis_pljava_jar',  false);" and "SELECT
sqlj.add_type_mapping('geometry', 'org.postgis.pljava.PLJGeometry');".
There's no way we can deal with that sort of thing automatically, so
we'll have to support uninstall scripts regardless.

The question then becomes: is it worth trying to do stuff
automatically if we provide a manual method anyway? I think the answer
is probably yes, because having pgsql clean up automatically for the
vast majority of cases is a good thing. If it's only exotic cases that
need a manual uninstall script, why force one on everyone else?

Cheers

Tom

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: New style of hash join proposal
Next
From: Paul van den Bogaard
Date:
Subject: CLogControlLock