Re: [GENERAL] Updating column on row update

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Updating column on row update
Дата
Msg-id 14476.1258990506@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Updating column on row update  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: [GENERAL] Updating column on row update
Re: [GENERAL] Updating column on row update
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Partitioning option for COPY
Следующее
От: Emmanuel Cecchet
Дата:
Сообщение: Re: Partitioning option for COPY