Thread: Re: Database owner installable modules patch
"Tom Dunstan" <pgsql@tomd.cc> writes: > - I'd like to add pg_depend entries for stuff installed by the module > on the pd_module entry, so that you can't drop stuff required by the > module without uninstalling the module itself. There would have to be > either a function or more syntax to allow a script to do that, or some > sort of module descriptor that let the backend do it itself. > > - Once the issue of loading a dll from inside the module's directory > is done, I'd like to look for an e.g. module_install() function inside > there, and execute that rather than the install.sql if found. Ditto > for uninstall. 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <stark@enterprisedb.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
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <pgsql@tomd.cc> wrote: > On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <stark@enterprisedb.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
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
"Tom Dunstan" <pgsql@tomd.cc> writes:
> 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.
Well, that just begs the question of what those commands actually *do*.
It seems not unlikely that they'd be inserting data into tables that
would belong to the module, in which case an uninstall that dropped
the table would be fine.
I still like the idea of uninstall being just a "DROP MODULE" with
subsequent cascading. If you want to argue that that isn't sufficient
you really need a pretty convincing example why not.
regards, tom lane
On Mon, Apr 7, 2008 at 7:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Tom Dunstan" <pgsql@tomd.cc> writes:
> > 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.
>
> Well, that just begs the question of what those commands actually *do*.
> It seems not unlikely that they'd be inserting data into tables that
> would belong to the module, in which case an uninstall that dropped
> the table would be fine.
Those tables belong to a *different* module, though. I'm picturing
three modules here: pljava, postgis, and a postgis-pljava support
module that requires the first two, since it should be possible to
install postgis without requiring pljava. The above stuff was from the
install script of the postgis-pljava code, but inserted data into
tables owned by pljava.
Cheers
Tom
On Sun, Apr 06, 2008 at 11:29:50PM +0100, Gregory Stark wrote: > I wonder if there's much of a use case for any statements aside from > CREATE statements. Yes. Some modules could have COPY or equivalent in them, as they could easily contain data. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate