Skip site navigation (1) Skip section navigation (2)

Dynamically loadable modules

From: Mattias Kregert <matti(at)algonet(dot)se>
To: David Gould <dg(at)illustra(dot)com>
Cc: Brandon Ibach <bibach(at)infomansol(dot)com>, hackers(at)postgreSQL(dot)org
Subject: Dynamically loadable modules
Date: 1998-03-25 16:36:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
David Gould wrote:
> >    How about this as a compromise.  We make these packages available
> > in the contrib or other such area as loadable modules as well as
> > making them available right in the main backend code, but setup
> > configure options to enable/disable them, so when I compile, I can say
> > "--without-geometry" to compile without those types and functions.  If
> > I want to add them back in later, I can compile the loadable module
> > version and add them in.
> I don't particularly like this model of adding extensions either. It implies
> that you have to rerun configure and build the whole system to add a module.
> In fact, all that is needed is to build the module and run the setup
> scripts and the running database picks up the new functionality.

That's the nice thing with Linux. You can throw out the sound driver
any time and insert a new one whenever you want to. If I decide to
use the MIDI port, I can rmmod the old driver and insmod the new
one with midi support...
If I connect a Wingdogs PC  to my network, I can insmod smbfs and
then I can mount the windows file resources from my Linux box. No need
to upgrade kernel or reboot.
If someone comes up with a new super-NFS, I just unmount my nfs's,
insmod super-nfs, and mount -a -t nfs...

With loadable modules in PostgreSQL, you could upgrade the ORACLE
compatability module by typing "make modules modules-install".

No need to kill all backends and postmaster, deal with angry users,
make backups, install new binaries, dump-and-restore, track down bugs,
and so on.

It would also be easier to contribute to PostgreSQL by creating
modules, than having to submit patches to the server core...
Let's say I have made a storage manager for tapes. It would be easier
to make a module which used a standard set of "modules" functions
to register the new manager in the core, than submitting patches
to be included in the core...
And if something causes troubles, just remove that module! Then it
would not be a big problem if a new feature was buggy. Perhaps it
would be easier to find bugs then (binary search - remove module
by module).

Just imagine Linux if people had to submit patches to the kernel
instead of just writing their drivers as modules!!!

/* m */

In response to

pgsql-hackers by date

Next:From: Mattias KregertDate: 1998-03-25 16:38:54
Subject: Re: [HACKERS] Data type removal
Previous:From: Jan WieckDate: 1998-03-25 16:33:01
Subject: Re: AW: [HACKERS] Begin statement again

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group