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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
