Re: Database owner installable modules patch
От | Tom Dunstan |
---|---|
Тема | Re: Database owner installable modules patch |
Дата | |
Msg-id | ca33c0a30804070346m256d7c55na0832ac1d86a597f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Database owner installable modules patch ("Tom Dunstan" <pgsql@tomd.cc>) |
Ответы |
Re: [PATCHES] Database owner installable modules patch
|
Список | 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 по дате отправления: