"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Uh, I seem to have missed where the crash was in this example?
> I wasn't willing to dump my machine. However I could:
> A. Exhaust all resources
> B. Fill up my hard drive
> C. Render the application unusable for other users
> D. Lock out DDL operations by beginning a transaction
> E. Cause xid wrap around by leaving an open transaction idle and thus
> force a shutdown of postgresql
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.
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as would be the case if it were in
template0 for example.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
