On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers