]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Use LOAD not actual code execution to pull in plpython library.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 12 Jan 2016 01:06:36 +0000 (20:06 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 12 Jan 2016 01:06:47 +0000 (20:06 -0500)
commit5ef26b8de3a12b0766334a19665d8b0f494a6af8
tree855e54f4d2728b43606470c49d728af5d7424dfc
parentdb8fa56d6ad15621ad4f74667bfd59533408ce16
Use LOAD not actual code execution to pull in plpython library.

Commit 866566a690bb9916 is insufficient to prevent dump/reload failures
when using transform modules in a database with both plpython2 and
plpython3 installed.  The reason is that the transform extension scripts
use DO blocks as a mechanism to pull in the libpython library before
creating the transform function.  It's necessary to preload the library
because the dynamic loader won't do it for us on every platform, leading
to "unresolved symbol" failures when the transform library is loaded.
But it's *not* necessary to execute Python code, and doing so will
provoke a multiple-Pythons-are-loaded error even after the preceding
commit.

To fix, use LOAD instead of a DO block.  That requires superuser privilege,
but creation of a C function does anyway.  It also embeds knowledge of
the underlying library name for each PL language; but that's wired into
the initdb-time contents of pg_pltemplate too, so that doesn't seem like
a large problem either.  Note that CREATE TRANSFORM as such doesn't call
the language module at all.

Per a report from Paul Jones.  Back-patch to 9.5 where transform modules
were introduced.
contrib/hstore_plperl/hstore_plperl--1.0.sql
contrib/hstore_plperl/hstore_plperlu--1.0.sql
contrib/hstore_plpython/hstore_plpython2u--1.0.sql
contrib/hstore_plpython/hstore_plpython3u--1.0.sql
contrib/hstore_plpython/hstore_plpythonu--1.0.sql
contrib/ltree_plpython/ltree_plpython2u--1.0.sql
contrib/ltree_plpython/ltree_plpython3u--1.0.sql
contrib/ltree_plpython/ltree_plpythonu--1.0.sql