Tom Lane <tgl@sss.pgh.pa.us> writes:
> The next question is how come this regression test ever worked on that
> platform. The reason is that up till my changes for $SUBJECT, when you
> issued "CREATE LANGUAGE plpython2u" in a database that already had
> plpythonu installed, CREATE LANGUAGE found C functions of the expected
> names already present and so it didn't create new ones. This meant that
> only plpython.dll ever got loaded, not plpython2.dll, despite what the
> pg_pltemplate entry alleges about the shlib name for the latter.
Well if we would have a plpython_wrapper extension that loads the common
functions and the shared object, then a plpythonu and a plpython2u that
depends on the plpython_wrapper extension, would it solve the problem?
Instead of an ERROR when an extension you require isn't installed, the
code would have to recurse into installing it. That means maintaining a
stack of current extension being loaded, I guess.
Also, for external PLs it would allow people to distribute a couple of
extensions each time. The wrapper one that you have to install as a
superuser, possibly in template1, and the PL one that you can install as
the database owner. It could be a big enough deal in colo environments.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support