Re: [GENERAL] Updating column on row update - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Updating column on row update
Date
Msg-id 14476.1258990506@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Updating column on row update  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: [GENERAL] Updating column on row update  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: [GENERAL] Updating column on row update  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  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.

> 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.

The fact remains though that the looping performance of anything you can
cons up in straight SQL will be an order of magnitude worse than in
plpgsql; and it's a notation the average script kiddie will find pretty
unfamiliar.  So I think this still does represent some barrier.  Whether
it's enough of a barrier to justify keeping plpgsql out of the default
install is certainly debatable.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Partitioning option for COPY
Next
From: Emmanuel Cecchet
Date:
Subject: Re: Partitioning option for COPY