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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: New style of hash join proposal
Следующее
От: Paul van den Bogaard
Дата:
Сообщение: CLogControlLock