Re: [HACKERS] Database owner installable modules patch

On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> I wonder if there's much of a use case for any statements aside from CREATE
> statements. If we restrict it to CREATE statements we could hack things to
> create pg_depend entries automatically. In which case we wouldn't need an
> uninstall script at all.

Well, the example that got me interested in this stuff originally was
trying to make pl/java easier to install. It does a bunch of
CREATEs... and some GRANTs. Plus ISTM that a pretty common case might
be to create a table for some reference data and then fill it with
default values. Also, I just had a look at the postgis install script,
which at the very least seems to update an opclass entry after
creating it.

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.

One thing that's nice about arbitrary sql for install / uninstall is
that module authors can test it outside the context of doing an actual
module installation - they just execute their scripts.

> The hacks to do this seem pretty dirty but on the other hand the idea of
> having modules consist of a bunch of objects rather than arbitrary SQL
> actually seems cleaner and more robust.

It *does* seem cleaner for the examples that I've looked at. Are they
totally representative though? Not sure. It also implies a bunch more
work to create stuff, as we need to understand what's going on so as
to create those pg_depend entries. I'm receptive to the idea of
uninstall simply attempting to drop anything related to the module in
pg_depend in the correct order. I can't think of anything created by a
module that we couldn't represent there, and it's a nice way of
ensuring that an uninstall script cleans up properly.

Cheers

Tom