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

Re: Extensions User Design

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extensions User Design
Date: 2009-07-01 09:20:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

While backporting UUID stuff to 8.2 where I'll need it (I wish I could
have more impact on PostgreSQL upgrade schedules... who doesn't), I
faced a problem I didn't foresee, and that we maybe should think about.

The idea in this backport is to have UUID as an extension to 8.2, which
was plain easy to do once you remember about adding the
PG_FUNCTION_INFO_V1() macro calls where they fit. Then there's the
uuid-ossp contrib stuff, already packaged as an extension, but with code
dependancy to the UUID provided functions (uuid_in, uuid_out).

What I ended up doing was duplicating code in order not to have to tweak
local_preload_libraries, so that is self-contained.

Any advice or missing knowledge about loading modules which depends on
code from another module not already loaded in the backend is welcome :)

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>   - dependancy graph solving and automatic installation, with depends,
>>     recommends and suggest sections and with rules/setup to choose what to
>>     pull in by default...
> Uh-huh.  That'll be the day ...

So it seems we will have to teach the extension facility about loading
dependant extensions first when calling a function, which I guess we can
do as soon as we have the dependancies information in there?

(calling a function from 'MODULE_PATHNAME' will have the .so loaded, so
 I guess than knowing it depends on another 'MODULE_PATHNAME' will
 enable us to load those first)


In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-07-01 09:21:42
Subject: Re: 8.5 development schedule
Previous:From: Simon RiggsDate: 2009-07-01 07:58:06
Subject: Re: 8.5 development schedule

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