Re: extension_control_path

* Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)fr) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)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.

I'm a bit confused here- above you '+1'd packagers/sysadmins, but then
here you are saying that hackers will be setting it? Also, it strikes
me as a terrible idea to ship absolute object file names (which I assume
you mean to include path, given you say 'absolute') unless you're an
actual OS packaging system. I know OSX has some packaging system which
lets you install things that aren't-quite-the-OS, can a package
completely depend on the install path that the hacker decided upon for
the package initially? It's not relocatable at all on a given system?
Is there a 'shared' directory for all those packages into which each
package can drop files? How is the naming for those files handled? Is
there more than one such directory?

Presumably, that's what you'd want to set both the control path and the
dynamic extension path to- a directory of control files and a directory
of .so's, or perhaps one combined directory of both, for the simplest
setup. If you're working with a directory-per-package, then wouldn't
you want to have everything for that package in that package's directory
and then only have to add all those directories to one place in
postgresql.conf?

I've been trying to follow this thread pretty closely but perhaps I've
missed it (or forgotten it) and, if so, my apologies, but how exactly
are you envisioning PG, these GUCs, whichever OSX packaging system, and
your external tool working together?

> 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).

My questions about this are mostly covered above, but I did want to get
clarification- is this going to be on a per-system basis, as in, when
the package is installed through your tool, it's going to go figure out
where the package got installed to and rewrite the control file? Seems
like a lot of work if you're going to have to add that directory to the
postgresql.conf path for the control file anyway to then *also* have to
hack up the control file itself.

> > 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.

I can see some of the simplicity in that, though it strikes me as being
more-or-less equivilant to just searching the directory where the
control file exists first, if it isn't in the PG default, with the added
benefit that moving the base-install location for the modules would only
require updating the postgresql.conf rather than having to update it and
then also go modify every control file.

> > 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 understand your proposal better now that I understand how you're
planning to use it, but I'm still of the opinion that we might be able
to do better by our users by not hard-coding paths into every control
file.

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

I think we all aspire to do that. :)

Thanks,

Stephen