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/