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

From Tom Lane
Subject Re: [PATCHES] Database owner installable modules patch
Date
Msg-id 5038.1207578305@sss.pgh.pa.us
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 Dunstan" <pgsql@tomd.cc>)
List pgsql-hackers
"Tom Dunstan" <pgsql@tomd.cc> writes:
> 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.

Well, that just begs the question of what those commands actually *do*.
It seems not unlikely that they'd be inserting data into tables that
would belong to the module, in which case an uninstall that dropped
the table would be fine.

I still like the idea of uninstall being just a "DROP MODULE" with
subsequent cascading.  If you want to argue that that isn't sufficient
you really need a pretty convincing example why not.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Paul van den Bogaard
Date:
Subject: CLogControlLock
Next
From: "Pavel Stehule"
Date:
Subject: problem with locks on head, backend crash