Tom Lane wrote:
Certainly you can cause massive DOS-type problems in plain SQL without any access to plpgsql, but that type of juvenile delinquency isn't what concerns me. What I'm worried about is whether plpgsql isn't a useful tool for the sort of professional who would much rather you never knew he was there. It's perhaps true that with generate_series() for looping and CASE for conditionals, plain SQL is Turing-complete and therefore could do anything, but it'd be awfully unpleasant and inefficient to use as a procedural language. The pro who doesn't want you to know he's there is never going to try to do password cracking that way; the resource consumption would be large enough to be noticed. plpgsql on the other hand is fast enough to be a *practical* tool for nefarious purposes.
As a matter of interest, are there any other databases that have procedural languages that don't have them turned on by default? In fact, are there any that allow you to turn them off?
It certainly looks like MySQL's PL is always on, unless I'm missing something, and ISTR PL/SQL is always on in Oracle, although it's now quite some years since I touched it in anger.
I understand the argument about providing a platform for stealth computing, but our peers in the DB world don't seem too fussed, and neither do the world's security professionals.
(I should add that I think DBMS servers with sensitive or mission critical data should never be exposed to the Internet nor indeed to anything but a trusted network. All access by end users should be via middleware with appropriately restricted privileges - including restrictions on the creation of functions)
cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
