Re: Configurable path to look up dynamic libraries

Tom Lane writes:

> This is of little value unless the default is intelligently chosen.
> The default should be "$PGLIB", IMHO (inserted from configure's data).

This default has little value as well. Users don't generally put their
loadable modules in the same directory as a PostgreSQL installation.
Maybe they do for general-purpose contrib-like stuff, but then they might
as well use an absolute path. (Remember that a PostgreSQL installation
could well be under /usr/lib; think of all the things that reside there
that we have no business with.)

This also ties in somewhat with the fact that we have no default for
PGDATA, on purpose. If we can have arbitrarily located data locations the
system should not have a hard-wired in default for libraries (which are
usually tied to particular databases in particular database clusters).

> I do not believe that it's a good idea to allow the value to be changed
> at runtime, either --- do you expect that backends will remove
> already-loaded libraries in response to a change in the variable?

No, I would expect it to use the path for loading new libraries from then
on. People that use loadable libraries and C functions are superusers and
experienced enough to cope with this little (logical) fact. (Analogy:
When I change the PATH in my shell, the shell does not kill all processes
already running.)

The way I think this is most useful is in third-party provided
load_all_my_stuff.sql scripts, like:

set dynamic_library_path='/usr/local/foo/lib'; -- inserted by the package's build process

create function foo_xxx() ...

(Yes, you could do the same "inserted by package's build process" into
each of the create function's, but this way it's much cleaner.)

I also envision this to be used as part of dump/restore. pg_dump might
have an option "do not dump full path", and it would insert a 'set
dynamic_library_path'. This would work like the previous case, really.

Also think of a developer wanting to try out different sets of libraries
with a common load script.

If we make this parameter postmaster start only then we really don't gain
anything. We don't even gain the minimal expected convenience in pg_dump
because you would force all modules to reside in a certain place where
administrators would least like them to be.

> Also, it'd be really nice if a platform-dependent suffix (.so, .sl,
> etc) were automatically added to the given library name, if one's not
> present already.

Yes.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter