I've committed changes to implement the cut-down form of this proposal:
http://archives.postgresql.org/pgsql-hackers/2005-08/msg01185.php
discussed here:
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00138.php
Barring further changes, we'll have a hard-wired template list for 8.1
and a real system catalog in 8.2. So there's a choice now for PLs that
are not part of the core distribution: do you want to be listed in the
hard-wired template?
The advantages of being listed are:
1. Reloading old dumps that involve your language should be easier,
since problems like version-specific paths to shared libraries will
go away.
2. Your PL support functions will end up in pg_catalog instead of
the public schema, which will please people who'd like to remove public
from their installations.
The main disadvantage I can see is that you won't easily be able to
change your PL creation parameters (eg, add a validator function)
over the lifespan of the 8.1 release. So depending on your development
roadmap you might think this a bad tradeoff.
If you want to be listed, let me know. What I need to know to list you
is values for this table:
typedef struct
{ char *lanname; /* PL name */ bool lantrusted; /* trusted? */ char *lanhandler;
/* name of handler function */ char *lanvalidator; /* name of validator function, or NULL */ char
*lanlibrary; /* path of shared library */
} PLTemplate;
As examples, the entries for the core PLs are
{ "plpgsql", true, "plpgsql_call_handler", "plpgsql_validator", "$libdir/plpgsql" }, { "pltcl",
true,"pltcl_call_handler", NULL, "$libdir/pltcl" }, { "pltclu", false, "pltclu_call_handler", NULL,
"$libdir/pltcl" }, { "plperl", true, "plperl_call_handler", "plperl_validator", "$libdir/plperl" },
{ "plperlu", false, "plperl_call_handler", "plperl_validator", "$libdir/plperl" }, { "plpythonu", false,
"plpython_call_handler",NULL, "$libdir/plpython" },
regards, tom lane