Re: Including PL/PgSQL by default
От | Tom Lane |
---|---|
Тема | Re: Including PL/PgSQL by default |
Дата | |
Msg-id | 14288.1203621328@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Including PL/PgSQL by default ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: Including PL/PgSQL by default
Re: Including PL/PgSQL by default Re: Including PL/PgSQL by default |
Список | pgsql-hackers |
"Joshua D. Drake" <jd@commandprompt.com> writes: >> Uh, I seem to have missed where the crash was in this example? > I wasn't willing to dump my machine. However I could: > A. Exhaust all resources > B. Fill up my hard drive > C. Render the application unusable for other users > D. Lock out DDL operations by beginning a transaction > E. Cause xid wrap around by leaving an open transaction idle and thus > force a shutdown of postgresql Certainly you can cause massive DOS-type problems in plain SQL without any access to plpgsql, but that type of juvenile delinquency isn't what concerns me. What I'm worried about is whether plpgsql isn't a useful tool for the sort of professional who would much rather you never knew he was there. It's perhaps true that with generate_series() for looping and CASE for conditionals, plain SQL is Turing-complete and therefore could do anything, but it'd be awfully unpleasant and inefficient to use as a procedural language. The pro who doesn't want you to know he's there is never going to try to do password cracking that way; the resource consumption would be large enough to be noticed. plpgsql on the other hand is fast enough to be a *practical* tool for nefarious purposes. Anyway, as I said before, I don't object to installing plpgsql by default. What I do object to is installing it in a way that makes it difficult for the DBA to remove it, as would be the case if it were in template0 for example. regards, tom lane
В списке pgsql-hackers по дате отправления: