Re: [HACKERS] Updating column on row update - Mailing list pgsql-general

From Andrew Gierth
Subject Re: [HACKERS] Updating column on row update
Date
Msg-id 87ws1h5lfs.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: [HACKERS] Updating column on row update  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Updating column on row update  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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)

pgsql-general by date:

Previous
From: Thom Brown
Date:
Subject: Re: [HACKERS] Updating column on row update
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] Updating column on row update