Tom,
I think this patch is plenty complicated enough without adding useless
restrictive options.
+1 for no additonal GUC options.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
[ catching up on back email ]
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Yoshiyuki Asaba" <[EMAIL PROTECTED]> writes:
>> 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 varia
Hans-Juergen Schoenig wrote:
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
i don't think statement_timeout is a good idea at all.
it is not deterministic. depending on the load on the server some
queries will execute while others fail.
a separate GUC is needed.
I
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
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.
Hi,
From: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Sun, 18 May 2008 23:22:02 +0200
> But I have a little problem with the output.
> If it's not obvious, here is the query tweaked a little below.
...
> Can we get the rows in tree order, please?
On Sat, May 24, 2008 at 05:01:11AM +0900, Yoshiyuki Asaba wrote:
> Hi,
>
> From: David Fetter <[EMAIL PROTECTED]>
> Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
> Date: Fri, 23 May 2008 11:26:30 -0700
>
> > Where is the new patch?
>
> I will create the revised patch on June. This is a patch
Hi,
From: David Fetter <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Fri, 23 May 2008 11:26:30 -0700
> Where is the new patch?
I will create the revised patch on June.
This is a patch for this problem.
*** ../../pgsql/src/backend/executor/nodeRecursivescan.c
On Sat, May 24, 2008 at 03:21:01AM +0900, Yoshiyuki Asaba wrote:
> Hi,
>
> From: David Fetter <[EMAIL PROTECTED]>
> Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
> Date: Sun, 18 May 2008 11:47:37 -0700
>
> > I tried a bunch of different queries, and so far, only these two
> > haven't worked.
Hi,
From: David Fetter <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Sun, 18 May 2008 11:47:37 -0700
> I tried a bunch of different queries, and so far, only these two
> haven't worked. Any ideas what I'm doing wrong here?
>
> WITH RECURSIVE t(n) AS (
> SELECT 1
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> >> 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 ha
> >> 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 n
"Yoshiyuki Asaba" <[EMAIL PROTECTED]> writes:
> Hi,
>
> From: David Fetter <[EMAIL PROTECTED]>
> 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 aro
Hi,
From: David Fetter <[EMAIL PROTECTED]>
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.
> >
>
> On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
> > WITH RECURSIVE patch V0.1
> >
> > Here are patches to implement WITH RECURSIVE clause. There are some
> > limitiations and TODO items(see the "Current limitations" section
> > below). Comments are welcome.
> >
> > 1. Credit
> >
On Mon, May 19, 2008 at 05:57:17PM +0900, Yoshiyuki Asaba wrote:
> Hi,
>
> > 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
Yoshiyuki Asaba írta:
Hi,
From: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
Also, it seems there are no infinite recursion detection:
# with recursive x(level, parent, child) as (
select 1::integer, * from
Hi,
From: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
> >> Also, it seems there are no infinite recursion detection:
> >>
> >> # with recursive x(level, parent, child) as (
> >>select 1::integer, * from test_con
Merlin Moncure wrote:
On Sun, May 18, 2008 at 5:22 PM, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
Can we get the rows in tree order, please? I.e. something like this:
Is ordering by tree order defined in the standard when no explicit
order is given? If not, it probably returns them
On Sun, May 18, 2008 at 5:22 PM, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Can we get the rows in tree order, please? I.e. something like this:
Is ordering by tree order defined in the standard when no explicit
order is given? If not, it probably returns them in the order they
are pulled up
David Fetter írta:
On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
WITH RECURSIVE patch V0.1
Here are patches to implement WITH RECURSIVE clause. There are some
limitiations and TODO items(see the "Current limitations" section
below). Comments are welcome.
1. Credit
These pat
On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
> WITH RECURSIVE patch V0.1
>
> Here are patches to implement WITH RECURSIVE clause. There are some
> limitiations and TODO items(see the "Current limitations" section
> below). Comments are welcome.
>
> 1. Credit
>
> These patches we
21 matches
Mail list logo
