Re: extension_control_path - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: extension_control_path
Date
Msg-id m2vbw1k0fh.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: extension_control_path  (Stephen Frost <sfrost@snowman.net>)
Responses Re: extension_control_path  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
>> Who do you think should have a say about where to load the dynamic
>> librairies from?  hackers, packagers, system admins, dbas or users?
>
> My gut feeling on this is packages and sysadmins.  Do you see it

+1

>> Who do you think is currently editing the setup that decides where to
>> load the dynamic librairies from, which is spread into SQL scripts,
>> extension control file, postgresql.conf and pg_config --pkglibdir?
>
> I agree that packagers and sysadmins will be setting this up initially,

Not quite, because of the ability to ship absolute object file names in
the SQL script and the extension control files, edited by hackers.

The third party tool I'm talking about will have to edit those files at
packaging time in order to get the control back to where you want it.

> but it strikes me as a bit silly to ask the sysadmins to go modify the
> control file path and then also have to modify the dynamic library load
> path when they're setting them to the same thing.

Well, the point is that if you edit the control file, then you don't
have to care about the dynamic_library_path at all, because you're going
to setup absolute object file names (or location).

> Related to this, as I've asked repeatedly on this thread- what is the
> plan for dealing with namespace overlaps?  As in, the admin happily goes
> in and sets dynamic_library_path to '$libdir:/path/to/new/hstore' and
> then tries to CREATE EXTENSION hstore; with the -contrib packages
> installed?

My proposal is to edit the control file module_pathname property to the
right absolute location within the new hstore binary packaging. That
responsibility is then given to the new third party tool, aimed at both
packagers and system admins.

> Part of the reason that I'm pushing for a change here is to try and
> address that problem.  I'd appreciate some feedback on it.

Within the way I see things, this problem just doesn't exist, by design.

> I was referring to the apparent role reversal between us, with me trying
> to get PG to do more and you pushing to have more in an external tool.
> It wasn't that long ago that our positions were swapped.

Well you know, I actually read my emails and learn from them.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: extension_control_path
Next
From: Peter Geoghegan
Date:
Subject: Re: jsonb and nested hstore