From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "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 21:04:51 |
Message-ID: | 20060411210451.GC411@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 11, 2006 at 05:01:17PM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
> >> 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.
>
> > The function I sent memoizes to a table, which avoids the stack
> > space problem you mentioned.
>
> In general that's not possible, and even for the specific case, it
> still looks to me like fib(n) will use O(n) recursion levels if the
> table is initially empty.
I don't get your not getting this 'cause you're a very smart guy. Are
you under the impression that an attacker will stop because he has to
try a few times?
Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-11 21:20:02 | Re: plpgsql by default |
Previous Message | Tom Lane | 2006-04-11 21:01:17 | Re: plpgsql by default |