Re: plpgsql by default

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: plpgsql by default
Дата
Msg-id 10357.1144787705@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: plpgsql by default  ("Jim C. Nasby" <jnasby@pervasive.com>)
Ответы Re: plpgsql by default  (David Fetter <david@fetter.org>)
Список pgsql-hackers
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Rather than debate how turing complete SQL is, look at the real issue:
> is a compromised system with plPGSQL installed more dangerous than a
> compromised system without plPGSQL. As far as I can see, it's not.

You're disregarding the possibility that plpgsql itself is the source of
a security hole ...

More realistically, though, the theoretical point that you can do
arbitrary calculations by turning loops into recursive SQL functions is
mostly just theoretical, and the reason is that you won't be able to
loop very many times before running out of stack space.  (On my machine
it looks like you can recurse a trivial SQL function only about 600
times before hitting the default stack limit.)  If you have an exploit
that involves moderate amounts of calculation within the server --- say,
brute force password cracking --- the availability of a PL will render
that exploit actually practical, whereas with only SQL functions to work
with it won't be.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kris Jurka
Дата:
Сообщение: Re: [PATCHES] schema-qualified SET CONSTRAINTS
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: OS cached buffers (was: Support Parallel Query Execution in Executor)