Tom Lane fb6fcbd33f Use LOAD not actual code execution to pull in plpython library. ... Commit 866566a690 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.		2016-01-11 20:06:36 -05:00
..
expected	Add CASCADE support for CREATE EXTENSION.	2015-10-03 18:23:40 +02:00
sql	Add CASCADE support for CREATE EXTENSION.	2015-10-03 18:23:40 +02:00
.gitignore
hstore_plpython2u--1.0.sql	Use LOAD not actual code execution to pull in plpython library.	2016-01-11 20:06:36 -05:00
hstore_plpython2u.control
hstore_plpython3u--1.0.sql	Use LOAD not actual code execution to pull in plpython library.	2016-01-11 20:06:36 -05:00
hstore_plpython3u.control
hstore_plpython.c	Dodge a macro-name conflict with Perl.	2015-11-19 14:54:11 -05:00
hstore_plpythonu--1.0.sql	Use LOAD not actual code execution to pull in plpython library.	2016-01-11 20:06:36 -05:00
hstore_plpythonu.control
Makefile	Sort $(wildcard) output where needed for reproducible build output.	2016-01-05 15:47:05 -05:00