Re: Procedural language permissions and consequences

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The first consequence is that we could get rid of createlang as the
> primary means of access control to languages. I would like to install all
> languages by default (excluding only those that haven't been included by
> "configure"). Would people be afraid if we made the trusted languages
> available to all users by default?

The arguments against this seem pretty thin on review. I would like to
be able to remove a language I don't want --- but I have no objection
to reversing the default.

> Furthermore, we can conveniently eliminate the problems related to finding
> all the language handlers as shared libraries. Since all languages are
> installed by default we can just link the handlers right into the
> postmaster, for which we don't need shared libraries. That should give a
> great boost to languages that are currently hard to build, i.e., PL/Perl
> and PL/Python. And the build system would become a lot simpler and more
> portable.

This I do *not* like. plpgsql is the single thing keeping us honest
on portability of shlib extensions. If the default and only tested
behavior is for statically-linked PL extensions, you can be sure that
dynamically-linked extensions will be suffering bit rot very soon.

And I do not see it as our problem that perl and python make life
unnecessarily difficult for those who would include them as libraries.
Tcl showed the way years ago; it's past time for those guys to see the
light, if they'd like to be adopted more widely.

See also Doug's points, nearby.

regards, tom lane