State of PL/Python build - Mailing list pgsql-hackers

The PL/Python build is now up to speed to as much as an extend as is under
our control.  I can also confirm that it works (as defined by the test
suite) with Python 1.5 and 2.1.  I've also put a chapter with
documentation in the programmer's guide.

We already know about the libpython (not-)shared library issue.  As it
turns out, not only is libpython generally not a shared library, there
isn't even a designed in way to make one.  See this discussion:

http://www.python.org/cgi-bin/faqw.py?req=show&file=faq03.030.htp

The way it's currently set up is that it will use whatever linking with
-lpythonx.y gives you.  Using the static library this way works on many
platforms, although it's not as efficient (each backend process image will
have its own copy of the library).  On some platforms it won't work at
all, of course.

In the distance you can hear the package maintainers rejoicing...

The second issue is that of dynamic loading.  The way it currently looks
on platforms with the dlopen() interface (which is what most platforms
have) is that when your Python code imports a module which is implemented
in a C shared library, the Python interpreter fires up its own dynamic
loading facilities.  However, due to the rules of relocation scoping,
those shared libraries cannot use the symbols defined in the plpython
image and therefore the libpython symbols themselves are not available.
Without those, no code works.

The way this is currently resolved is that all the C shared libraries that
form part of the modules that you might want to use are linked into
plpython.so directly, which puts them into a different relocation group,
so they have access to the symbols of libpython.  This is a stupid hack,
of course.

The real fix is to change the dynamic loader(s) to make use of the
RTLD_GLOBAL flag, which makes all dlopen'ed symbols available to everyone.
Personally, I don't see any harm in using this option.  Does anyone else?
(In fact, if someone were to create an untrusted PL/Perl language he would
probably run into this problem as well.)

Sounds a bit complicated?  See this documentation:


http://docs.sun.com:80/ab2/coll.40.5/REFMAN3/@Ab2PageView/325438?DwebQuery=dlopen&oqt=dlopen&Ab2Lang=C&Ab2Enc=iso-8859-1

Resolving this issue on non-dlopen platforms is left as an exercise.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter