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 по дате отправления: