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-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
On Sat, May 24, 2008 at 05:08:51AM -0700, David Fetter wrote:
> On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
> > WITH RECURSIVE patch V0.1
>
> Please find updated patch with bug fixes from Yoshiyuki Asaba and
> Michael Meskes. Any mistakes in it are mine. :)
As promised, the mis
[ 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.
On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
> WITH RECURSIVE patch V0.1
Please find updated patch with bug fixes from Yoshiyuki Asaba and
Michael Meskes. Any mistakes in it are mine. :)
Cheers,
David.
--
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 377
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 i
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 t
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/nodeRecurs
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, onl
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 RECU
"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 May 19, 1:17 am, [EMAIL PROTECTED] (David Fetter) wrote:
> On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
> > It's quite possible to have clauses which will limit the output but
> > not in a way the database can determine. Consider for example a
> > tree-traversal for a binary t
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::i
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 (
Gregory Stark írta:
This is indeed really cool. I'm sorry I haven't gotten to doing what I
promised in this area but I'm glad it's happening anyways.
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
Can we get the rows in tree order, please?
...
After all, I didn't specify any ORDER BY cl
This is indeed really cool. I'm sorry I haven't gotten to doing what I
promised in this area but I'm glad it's happening anyways.
"Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> Can we get the rows in tree order, please?
>...
> After all, I didn't specify any ORDER BY clauses in the base, r
"David Fetter" <[EMAIL PROTECTED]> writes:
> On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
>> "Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
>> > Also, it seems there are no infinite recursion detection:
>> >
>> > # with recursive x(level, parent, child) as (
>> >select 1::i
On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
> "Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> > Also, it seems there are no infinite recursion detection:
> >
> > # with recursive x(level, parent, child) as (
> >select 1::integer, * from test_connect_by where parent is null
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
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 were developed by Yoshiyuki Asaba ([EMAIL PROTECTED])
with some discussions with T
29 matches
Mail list logo
