On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <[EMAIL PROTECTED]> wrote: > 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.
> > 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. This has been bouncing around in my head a bit. I was picturing the module code itself having to understand all the CREATE statements in order to set up the dependencies... but perhaps an easier way would simply be to have the create statements themselves insert a pg_depend entry when they're done, if they detect that we're currently installing a module. There's already a flag for that that the superuser code looks at in the patch. Maybe you were ahead of me, and this was the hack that you were referring to. :) I tend to hate global flags like that because they leave weird non-obvious dependencies across the codebase, but perhaps it's the best way to do it in this case. It would mean hacking every create command in the system to understand it, though. :( 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
