Re: [HACKERS] Updating column on row update

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

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: [HACKERS] Updating column on row update
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] Updating column on row update