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

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane wrote:
>> We know we have a problem with hard-coded paths
>> in old dumps.

> This is irrelevant for non-core languages. If I have PL/foo 1.0
> installed and upgrade from PostgreSQL 8.0 to 8.1, then I have to
> manually recompile PL/foo and install the shared library. So manual
> intervention is required in any case and no template system of any kind
> will help.

Certainly you have to install new software, but that is a task exactly
equivalent to installing the new version of Postgres itself. The
problem being addressed here is fixing wrong information in your pg_dump
scripts, and that is just as real for non-core as core PLs. The
proposal *will* fix the need for manual intervention while reloading
dump data.

> Moreover, the hard-coded paths will not be solved by your proposal.

On what basis do you assert that? The proposal will replace those paths
by "$libdir/plfoo" (or whatever is in the template), which is something
we should be able to go forward with indefinitely ... and if we can't,
a template update will fix it in some future release.

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

>> We know we have a problem with missing validators in
>> old dumps

> This is irrelevant for non-core languages.

Again, I see no basis for that assertion. It is only true to the extent
that non-core languages haven't created validators yet.

> 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. So I think your premise is faulty. You'll need to install the
8.1 version of that PL, and that very possibly will have a validator
where none existed before.

> ... The information in
> the dump is the only accurate information that exists about the
> existence of a validator.

Except that the information in the dump is likely *not* to be accurate.
It tells you the way things were some number of releases ago, and as
we've already seen, people frequently propagate their dumps forward
across multiple releases --- indeed, one would hope that they'd be able
to do so. We need to fix things so that that Just Works in the face of
improvements to PLs.

> You are assuming that during the
> update from PostgreSQL 8.0 to PostgreSQL 8.1 there will also be an
> upgrade from PL/foo 1.0 to PL/foo ${latest-at-time-of-8.1-release}, but
> there is simply no basis for assuming that.

How many of the past major releases have allowed a previous PL to be
used without any changes? Hardly any AFAIR, and 8.1 is certainly not
far behind the previous ones when it comes to making internal API
changes that affect PLs.

In any case, not one of these arguments seems to me to favor the
alternative of preloading definitions into pg_language: that preloaded
definition is going to be just as wrong as the template information, if
either one is wrong. Now it's true that a hardwired template table is
harder to fix than a system catalog, but we can get rid of the hardwired
table at the same cost (viz, a forced initdb) as adding preloaded
definitions. I don't see any other advantage to doing it that way.

One other response to your point about surprise or lack of it: in my
proposal, in a release or so everyone will just be doing "CREATE
LANGUAGE foo" and there will be no surprise that the system knows how to
fill in the low-level details. The handler functions will be relegated
to what they should have been all along: an implementation detail. But
I think that having CREATE LANGUAGE alter the permissions of an existing
entry would be a permanent security risk; it will never not surprise
people, because other forms of CREATE don't do that.

regards, tom lane