Re: [HACKERS] Updating column on row update

Andrew Gierth <andrew@tao11.riddles.org.uk>

From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: tgl@sss.pgh.pa.us (Tom Lane), PGSQL Mailing List <pgsql-general@postgresql.org>, pgsql-hackers@postgresql.org
Cc: Thom Brown <thombrown@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Craig Ringer <craig@postnewspapers.com.au>, Scott Marlowe <scott.marlowe@gmail.com>
Date: 2009-11-23T15:24:00Z
Lists: pgsql-hackers, pgsql-general
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 > Thom Brown <thombrown@gmail.com> writes:
 >> As for having plpgsql installed by default, are there any security
 >> implications?

 Tom> Well, that's pretty much exactly the question --- are there?  It
 Tom> would certainly make it easier for someone to exploit any other
 Tom> security weakness they might find.  I believe plain SQL plus SQL
 Tom> functions is Turing-complete, but that doesn't mean it's easy or
 Tom> fast to write loops etc in it.

Now that we have recursive CTEs, plain SQL is turing-complete without
requiring functions.

(Yes, I did actually prove this a while back, by implementing one of
the known-Turing-complete tag system automata as a single recursive
query. This proof is pretty boring, though, because you wouldn't
actually _use_ that approach in practice.)

Loops in plain SQL are no problem: see generate_series. The last time
we discussed this I demonstrated reasonably straightforward SQL
examples of how to do things like password-cracking (and that was long
before we had CTEs, so it would be even easier now); my challenge to
anyone to produce examples of malicious plpgsql code that couldn't be
reproduced in plain SQL went unanswered.

-- 
Andrew (irc:RhodiumToad)