Re: Extensions vs. shared procedural language handler functions

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