Re: Configurable path to look up dynamic libraries - Mailing list pgsql-hackers

Peter Eisentraut <peter_e@gmx.net> writes:
> 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.

That's a sweeping statement with little to back it up.  How do you know
that the usual procedure isn't to put things in $PGLIB?  That's
certainly what all our contrib packages do.  Even more to the point,
that's certainly where the PL call handler functions are.  I will
consider this feature utterly without value unless it allows the
standard declaration of plpgsql_call_handler to become
installation-independent, vizCREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUEAS 'plpgsql' LANGUAGE 'C';

> 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'd be willing to accept a default path that points to somewhere under
$PGDATA, although I consider this rather less useful.  Maybe we could
agree on a compromise two-entry default path: "$PGDATA/functions:$PGLIB"?
That would require some initdb-time shenanigans to set up, but if you
want to do it...

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

What?  What value would it have for pg_dump to do a set path operation?
The dump script would be unlikely to actually invoke any of the
functions it's loading.  By the time anyone tries to use the functions,
they'd be running in a different backend with a different path setting,
namely the default for the installation.

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

I fail to follow this claim also.  The point as far as I'm concerned is
that paths mentioned in CREATE FUNCTION ought to be relative to
someplace that's installation-dependent.  That way, when you dump out
and reload a CREATE FUNCTION command, the declaration is still good,
you just have to have put a copy of the function's shlib in the right
place for the new installation.
        regards, tom lane