Re: plpgsql by default

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: plpgsql by default
Date: 2006-04-11 20:35:05
Message-ID: 10357.1144787705@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <jnasby(at)pervasive(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-04-11 20:38:58 OS cached buffers (was: Support Parallel Query Execution in Executor)
Previous Message Kris Jurka 2006-04-11 20:30:18 Re: [PATCHES] schema-qualified SET CONSTRAINTS