Re: Attention PL authors: want to be listed in template table?

"Rupa Schomaker (lists)" <pgsql-hackers(at)lists(dot)rupa(dot)com> writes:
> Situation: A user installs a third-party PL that installs itself by
> updating the template catalog and then doing a createlang.
> Can the user simply do a dumpall/restore and get back into working
> order. Or will the user have to re-run the PL install script?

So? The dumpall/restore doesn't guarantee that the third-party PL
library is in place, so you still need to re-run the PL's install
script.

The point I think you are missing is that this change is an effort to
separate the existing treatment of PLs into two levels. The handler and
validator and library path properties of PLs are implementation details
that are best left outside the scope of pg_dump. pg_dump has never been
about exactly duplicating the original installation; it's about dumping
the user data in a form that can be transported to other installations
(possibly on different platforms) or to newer releases of Postgres.
Thus for example pg_dump intentionally avoids dumping and restoring any
built-in tables, functions, operators, etc. If it tried to do that
then it'd be useless for moving user data across PG versions, because
it'd wipe out whatever catalog updates the new version had made.

The basic point of the template patch is that the appropriate level of
abstraction for porting procedural languages across PG versions is
simply the language name --- the pg_dump script should say "CREATE
LANGUAGE plfoo", no more and no less. The other details such as the
library path name or the presence of a validator function are items
that can *and should* be allowed to vary across versions. So it
should be up to the new installation to provide valid values.

In the discussion yesterday, Peter provided some reasons why the valid
values might not be the same for every installation; but I continue to
think that they will be the same more often than not. On convenience
grounds it seems to me that it's best to provide built-in template
values for as many PLs as we can. When the destination installation
does have correct template values, the argument that pg_dump failed to
do it becomes moot.

regards, tom lane