Re: Extensions vs. shared procedural language handler functions

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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