Re: [HACKERS] [PATCHES] Database owner installable modules patch
Added to TODO:
* Implement a module capability for loading /contrib-style extensions
http://archives.postgresql.org/pgsql-patches/2008-04/msg00164.php
---
Tom Dunstan wrote:
Hi all
Here is a patch that provides an initial implementation of the module
idea that was kicked around over the last few days. While there
certainly wasn't consensus on list, enough people seemed interested in
the idea of database-owner-installable modules that I thought it was
worth having a play with.
The general idea, to recap, is to have modules, whether included in
the distribution a la contrib or installed separately, installed under
a directory such as $pkglib_dir/modules/foo. A typical module
directory might contain:
- foo.so/foo.dll
- install.sql
- uninstall.sql
- foo.conf
- some-other-file-needed-by-foo-module.dat
The module would be installed on the system, but the necessary scripts
to install it in a particular database have not been run. In
particular, the modules would not usually be install in template1.
Database owners themselves can then opt to enable a particular
installed module in their own database - they do not have to hassle a
sysadmin to do it for them.
Features of the patch:
- A database owner can issue the command INSTALL MODULE foo, and
pgsql will look for a $pkglib_dir/modules/foo/install.sql file to run,
and run it.
- The install script can do pretty much anything - the user is
treated as the superuser for the duration of the script. The main and
obvious usage is to create C language functions required by the
module.
- An entry is created in a new pg_module catalog. This is mainly to
guard against someone trying to install a module twice at this point,
but it may have other uses in the future (see below).
- UNINSTALL MODULE foo looks for and executes
$pkglib_dir/modules/foo/uninstall.sql and cleans up the catalog.
Here is a list of things that are either still to do before I'd
consider it worthy of inclusion (should the general approach be
considered acceptable), or which I'd like some guidance on:
- Currently the script is executed in one big SPI_execute call, and
so errors and NOTICEs print out the entire script as context. I'm not
sure how to break it up without writing a full parser - we must have
something available in the backend to break a string up into multiple
statements to execute, but I'm not sure where to look. Also, is there
a better way to do this than SPI?
- I've hacked in a bit of an end-run around permissions checks to
make the current user look like a super-user while a module script is
running. Is there a better way to do this?
- I can't create C language functions from dlls under the modules
dir. I'd like to be able to specify 'modules/foo/foo' as the library
name, but the backend sees a slash and decides that must mean the path
is absolute. I see two ways to fix this: change the existing code in
dfmgr.c to *really* check for absolute/relative paths rather than the
current hack, or I could stick in a special case for when it starts
with modules/. I thought I'd get some guidance on-list. Do people
think that sticking the dll in with other resources for the module
under $pkglib_dir is a bad thing? (I think having everything in one
place is a very good thing myself).Is the existing check written the
way it is for a particular reason, or is it just good enough?
- It would be nice to create the empty modules dir when we install
pgsql, but while I suppose hacking a Makefile to install it is the way
to go, I'm not sure which one would be appropriate.
- Hack pgxs to install stuff into a modules dir if we give it some
appropriate flag.
- 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.
- Maybe a basic mechanism to allow a module to require another one.
Even just a SELECT require_module('bar') call at the top of a
script.
- It would be nice to suppress NOTICEs when installing stuff - the
user almost certainly doesn't care.
- Pick up config files in module directories, so that a module can
install and pick up config for itself rather than getting the sysadmin
to hack the global custom_variable_classes setting.
- Should plperl etc be done as modules so that their config can live
independently as well? And to allow modules to require them?
Some other nice to haves for
Re: [HACKERS] [PATCHES] Database owner installable modules patch
On Sat, May 10, 2008 at 11:02 AM, Bruce Momjian [EMAIL PROTECTED] wrote: Where are we on this? I haven't had time to do any work since the original patch. That patch was fairly basic - it just ran install / uninstall scripts and created catalog entries, and introduced some slightly exotic syntax to do it (INSTALL/UNINSTALL vs CREATE/DROP). The next version is intended to handle dependencies, which should make uninstallation straight forward for most cases. I was intending to revert the syntax creativity and make the commands CREATE/DROP too. I'll get a bit of time to look at both this and the enum patch this week. 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
Re: [HACKERS] [PATCHES] Database owner installable modules patch
Where are we on this?
---
Tom Dunstan wrote:
Hi all
Here is a patch that provides an initial implementation of the module
idea that was kicked around over the last few days. While there
certainly wasn't consensus on list, enough people seemed interested in
the idea of database-owner-installable modules that I thought it was
worth having a play with.
The general idea, to recap, is to have modules, whether included in
the distribution a la contrib or installed separately, installed under
a directory such as $pkglib_dir/modules/foo. A typical module
directory might contain:
- foo.so/foo.dll
- install.sql
- uninstall.sql
- foo.conf
- some-other-file-needed-by-foo-module.dat
The module would be installed on the system, but the necessary scripts
to install it in a particular database have not been run. In
particular, the modules would not usually be install in template1.
Database owners themselves can then opt to enable a particular
installed module in their own database - they do not have to hassle a
sysadmin to do it for them.
Features of the patch:
- A database owner can issue the command INSTALL MODULE foo, and
pgsql will look for a $pkglib_dir/modules/foo/install.sql file to run,
and run it.
- The install script can do pretty much anything - the user is
treated as the superuser for the duration of the script. The main and
obvious usage is to create C language functions required by the
module.
- An entry is created in a new pg_module catalog. This is mainly to
guard against someone trying to install a module twice at this point,
but it may have other uses in the future (see below).
- UNINSTALL MODULE foo looks for and executes
$pkglib_dir/modules/foo/uninstall.sql and cleans up the catalog.
Here is a list of things that are either still to do before I'd
consider it worthy of inclusion (should the general approach be
considered acceptable), or which I'd like some guidance on:
- Currently the script is executed in one big SPI_execute call, and
so errors and NOTICEs print out the entire script as context. I'm not
sure how to break it up without writing a full parser - we must have
something available in the backend to break a string up into multiple
statements to execute, but I'm not sure where to look. Also, is there
a better way to do this than SPI?
- I've hacked in a bit of an end-run around permissions checks to
make the current user look like a super-user while a module script is
running. Is there a better way to do this?
- I can't create C language functions from dlls under the modules
dir. I'd like to be able to specify 'modules/foo/foo' as the library
name, but the backend sees a slash and decides that must mean the path
is absolute. I see two ways to fix this: change the existing code in
dfmgr.c to *really* check for absolute/relative paths rather than the
current hack, or I could stick in a special case for when it starts
with modules/. I thought I'd get some guidance on-list. Do people
think that sticking the dll in with other resources for the module
under $pkglib_dir is a bad thing? (I think having everything in one
place is a very good thing myself).Is the existing check written the
way it is for a particular reason, or is it just good enough?
- It would be nice to create the empty modules dir when we install
pgsql, but while I suppose hacking a Makefile to install it is the way
to go, I'm not sure which one would be appropriate.
- Hack pgxs to install stuff into a modules dir if we give it some
appropriate flag.
- 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.
- Maybe a basic mechanism to allow a module to require another one.
Even just a SELECT require_module('bar') call at the top of a
script.
- It would be nice to suppress NOTICEs when installing stuff - the
user almost certainly doesn't care.
- Pick up config files in module directories, so that a module can
install and pick up config for itself rather than getting the sysadmin
to hack the global custom_variable_classes setting.
- Should plperl etc be done as modules so that their config can live
independently as well? And to allow modules to require them?
Some other nice to haves for some point in the future:
- Have some sort of install module privilege, rather than just a
check for database ownership
- Allow
Re: [HACKERS] [PATCHES] Database owner installable modules patch
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 [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
