Re: plpgsql by default - Mailing list pgsql-hackers

From Tom Lane
Subject Re: plpgsql by default
Date
Msg-id 10357.1144787705@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpgsql by default  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: plpgsql by default  (David Fetter <david@fetter.org>)
List 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 by date:

Previous
From: Kris Jurka
Date:
Subject: Re: [PATCHES] schema-qualified SET CONSTRAINTS
Next
From: "Jim C. Nasby"
Date:
Subject: OS cached buffers (was: Support Parallel Query Execution in Executor)