Re: plpgsql by default

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
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:01:17
Message-ID: 10657.1144789277@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2006-04-11 21:04:51 Re: plpgsql by default
Previous Message Jim C. Nasby 2006-04-11 20:54:56 Re: Support Parallel Query Execution in Executor