Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] WITH RECURSIVE patch V0.1

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Yoshiyuki Asaba" <y-asaba(at)sraoss(dot)co(dot)jp>
Cc: <david(at)fetter(dot)org>, <zb(at)cybertec(dot)at>, <ishii(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] WITH RECURSIVE patch V0.1
Date: 2008-05-21 15:23:34
Message-ID: 87lk23of49.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Yoshiyuki Asaba" <y-asaba(at)sraoss(dot)co(dot)jp> writes:

> Hi,
>
> From: David Fetter <david(at)fetter(dot)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!

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2008-05-21 15:45:32
Subject: plpgpsm future
Previous:From: Yoshiyuki AsabaDate: 2008-05-21 14:34:22
Subject: Re: [HACKERS] WITH RECURSIVE patch V0.1

pgsql-patches by date

Next:From: Joshua D. DrakeDate: 2008-05-21 16:48:50
Subject: Re: [HACKERS] WITH RECURSIVE patch V0.1
Previous:From: Yoshiyuki AsabaDate: 2008-05-21 14:34:22
Subject: Re: [HACKERS] WITH RECURSIVE patch V0.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group