Re: [PATCHES] WITH RECURSIVE patch V0.1 - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: [PATCHES] WITH RECURSIVE patch V0.1
Date
Msg-id 87lk23of49.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [PATCHES] WITH RECURSIVE patch V0.1  (Yoshiyuki Asaba <y-asaba@sraoss.co.jp>)
Responses Re: [PATCHES] WITH RECURSIVE patch V0.1
Re: [PATCHES] WITH RECURSIVE patch V0.1
List pgsql-hackers
"Yoshiyuki Asaba" <y-asaba@sraoss.co.jp> writes:

> Hi,
>
> From: David Fetter <david@fetter.org>
> Subject: Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
> Date: Mon, 19 May 2008 04:36:30 -0700
>
>> > > I think it's the other way around. The server should not emit
>> > > infinite number of records.
>> >
>> > How about adding new GUC parameter "max_recursive_call"?
>>
>> Couldn't we just have it pay attention to the existing
>> max_stack_depth?
>
> Recursive query does not consume stack. The server enters an infinite
> loop without consuming stack. Stack-depth error does not happen.

We could have a separate guc variable which limits the maximum number of
levels of recursive iterations. That might be a useful feature for DBAs that
want to limit their users from issuing an infinite query.

Note that users can always construct their query to limit the number of
recursive iterations. So this would only be useful for DBAs that don't trust
their users and want to impose a limit. It doesn't add any actual expressive
power that SQL doesn't have already.

The recursive query syntax in the spec actually does include the ability to
assign an output column to show what level of recursive iteration you're on.
So alternately we could have a GUC variable which just allows the DBA to
prohibit any recursive query without such a column and a fiter imposing a
maximum value on it. That's probably the most appropriate option.


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's Slony Replication support!

pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: proposal: table functions and plpgsql
Next
From: "Joshua D. Drake"
Date:
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1