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