On 5/31/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> On Wed, May 31, 2006 at 01:08:41PM +0300, Marko Kreen wrote:
> > On 5/8/06, Martijn van Oosterhout <kleptog@svana.org> wrote:
> > >All it requires is to include the header "pgmagic.h" and to put
> > >somewhere in their source:
> > >
> > >PG_MODULE_MAGIC
> >
> > Could you serve this as special docstring instead? Eg:
> >
> > PG_MODULE(foomodule)
> >
> > is mandatory, there you can to your magic, and optional:
>
> <snip>
>
> I like it, but I'm not sure there's enough consensus for that. I've
> suggested before including install info inside the modules themselves
> but there doesn't seem to be much interest in that.
I am not suggesting to try to go all the way, just to make sure that
your current patch fits into that direction.
> Apart from that there's issues with implementation. The Linux kernel
> can do it easily because it knows it will be using ELF, thus can use
> sections to store this info. Postgresql has to support many more types,
> making things like this tricky (but not impossible).
PostgreSQL already requires symbol loading functionality
for V1 function signatures, so per-module symbols won't be
much burden.
> Personally I'd like postgres to move to a system where external modules
> can easily be installed, uninstalled and upgraded. However, I've not
> seen the demand yet.
Demand happens only when users get used to such niceties on some
other databases. Considering that PostgreSQL is extensibility-wise
most advanced database and anything we offer is worlds best,
there won't be any demand in years to come.
I rather think we should create that demand. Tasks like
- see what modules are installed in database.
- install module
- remove module
are rather clunky in current setup. Making them easier would be good thing.
Ofcourse, its easy to tell others to do things. I'll try to hack on that area
myself also. If not earlier then maybe on Summit Code Sprint at least.
--
marko
