Re: [HACKERS] Database owner installable modules patch

On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <pgsql(at)tomd(dot)cc> wrote:
> 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.

> > 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