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

Tom Lane wrote:
> Now this certainly discriminates against installing PLs outside
> $libdir, but I haven't heard any good reason why people would need to
> do that.

Development, testing, staging, ...

> > If I have PL/foo 1.0
> > installed and upgrade from PostgreSQL 8.0 to 8.1, the validator in
> > PL/foo 1.0 will not magically appear or disappear.
>
> As a general rule, PLs have to at least be recompiled to move to a
> new release of the backend, and usually need some source code
> tweaking as well.

You keep saying that, but the fact is that most of the non-core PLs will
work just fine across several releases, if only because they have some
#ifdef's. So, no, you do not need to upgrade your PLs when you upgrade
PostgreSQL. You really don't. You just recompile them and put them
back in the same place. There are certainly constraints and
exceptions, but as a general rule it simply is not the case. If it
were, I would not have started this discussion.

Taking a step back and considering this "validator" business in a more
general context: Basically, the validator is just a property that may
or may not be applicable to a C function hidden inside a shared
library. We don't know what's in the shared library, so we (currently)
have to rely on the meta information in the dump to find out. This is
a special case of a more general problem, which is why I mentioned
PostGIS earlier. Any "plug-in" will evolve, and if it's just a bit
sophisticated it will have fairly tight dependencies on the server
version, which is certainly the case for much of the GIS and GiST
stuff. So here we have the same problem. The old dump will have the
meta-information on the old plug-in version. Under your theory, which
is surely true in certain cases, the user will have to upgrade the
plug-in at the same time. So the restore of the dump will have the
old, now wrong information. I don't suppose hard-coding the PostGIS
schema and ignoring special cases of CREATE FUNCTION will be the
answer.

One might object that these cases -- procedural languages and PostGIS
sort of things -- are different, but they are not. The chance that an
upgrade of PostgreSQL will require a version upgrade of the plug-in is
about the same. Certainly, the number of users of PostGIS and the
various GiST modules (FTS et al.) is comparable to, if not higher than
that of some of the PLs. So that means two things:

1. The problem is much worse.
2. The problem is really much less bad because external plug-ins, PL or
not, are often coded to work with multple server versions. And they
should be, because otherwise the work forced upon the development teams
to synchronize and the users to figure all that out will grow more than
linearly.

> In any case, not one of these arguments seems to me to favor the
> alternative of preloading definitions into pg_language:

That is not the alternative I am proposing. Your template idea,
hard-coded even, is just fine for core languages. For non-core
languages I am proposing that we simply do nothing because the problem
we are solving does not exist, or at least has a wildly different
nature.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/