Tom Lane wrote:
> The denial of service risk in particular (whether intentional or
> accidental) goes way up.
Does it really go "way up"? A malicious user who can execute SQL can DOS
the database trivially. Doing the (non-trivial) infrastructure work to
fix that is probably a good idea, but I don't see that not installing
pl/pgsql by default is going to make much of a difference.
> Another problem with this proposal is that installations without
> shared-library support will stop working entirely. I suppose we could
> get around that by building plpgsql into the core backend instead of as
> a shared library
That would be one solution. Another would be to only install pl/pgsql by
default when shared libraries are available. While that would mean
pl/pgsql wouldn't be available on platforms without shared libraries,
that's no worse than the status quo.
> Also, your proposal as worded does not seem to mean "installed by
> default", it means "installed, period". How would a DBA who doesn't
> want it get rid of it?
If we effectively just ran the CREATE FUNCTION and CREATE LANGUAGE
commands for pl/pgsql in a late stage of initdb, the language and its
associated functions wouldn't be builtin. The DBA would then be able to
drop pl/pgsql via droplang (which might need to be hacked up a bit to do
this).
-Neil