Re: pg_pltemplate entries for external PLs

Tom Lane wrote:
>> Basically, we have no information about what the proper parameters of external
>> languages would be. (We have some pretty good ideas, but that's not the
>> same.) Especially if we override the trusted/untrustedness, we could create
>> complete disaster.
>
> Presumably we'd only insert such entries with the concurrence/approval
> of the PL's author, so this argument seems pretty darn weak to me.

I have argued this problem to death before. Highlights:

http://archives.postgresql.org/pgsql-hackers/2005-09/msg00353.php
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00370.php
http://archives.postgresql.org/pgsql-hackers/2005-09/msg00379.php

Few people followed me, but then again, I think few people have had the
amount of interaction with PL development and packaging across many PLs,
PG releases, and operating system releases.

The consequences from implementing this would be severe and real, versus
what I can only understand as a small convenience gain (typing CREATE
LANGUAGE versus running some small .sql script).

From a packager's perspective, this development would be horrible.
You'd either have to tie all postgresql packages and PL packages
together by exact version, thus severely obstructing progress and
modularity. PL packages might, and usually do, have other dependencies,
and pretty soon you will have a huge fixed-version dependency chain
between all programming languages implementations in the distribution.
The alternative would be to request pltemplate updates as PLs are
released, which would require initdb at random times during a stable
release life.

And no, I don't in general believe what the authors say. For example,
you can compile PL/Java in various ways, and the properties depend on
which you you compile it. And PL/Ruby at one point had somewhat pecular
installation path requirements that would defeat templating. And I
don't believe that the authors were completely aware of those issues.
They normally only surface in downstream packaging.

It is one thing when you provide defaults. Or when the paths are weird
and you can patch them. But here you have defaults that you can't
override and that are stored in a different package. It's completely silly.

Please don't do it.