Re: Question regarding dynamic_library_path

"Thomas Hallgren" <thhal@mailblocks.com> writes:
> The LD_LIBRARY_PATH or PATH depending on system (Posix or Windows) that is
> effective when the dlopen function is called. All OS'es where shared
> libraries are possible have something similar.

The variations among platforms are great enough that I don't think you
can make such an assertion.

(To take one example, HPUX does have a variable like this --- they call
it SHLIB_PATH --- but it *is not used* unless a flag enabling it was
provided when the shlib was linked, and I think most people avoid doing
that.  Certainly we don't enable SHLIB_PATH in the shlibs we build in
the standard Postgres distribution.  Furthermore, AFAICT shl_load()
requires an exact path spec for the initial shared library; it won't
do a path search for that, only for dependencies.)

> The general idea is to let the OS find the shared library rather than have
> the backend do it by itself. There's a flaw in the current design. IMHO, it
> would be a good thing to improve it.

I think we'd just be buying into a lot of pain and platform-specific
behavior.  Up to now we have not depended on knowing how to
environmentally influence the dynamic linker, but with your proposal
Postgres would be immediately broken anywhere that we didn't have that
right.  And there are places we *couldn't* get it right, see HPUX.
I'm much more concerned about whether shared library loading works at
all than about whether it's possible for one shlib to autoload another.

If you want $libdir to be part of LD_LIBRARY_PATH on your platform, why
don't you just set that up in the postmaster start script?
        regards, tom lane