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:
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.
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
[ 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 variable which
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? I.e.
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
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. Any ideas
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 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 for this
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
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.
How about adding new GUC parameter max_recursive_call
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 around. The server should not emit
infinite number of records.
How about
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
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 have a separate guc
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_connect_by where
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
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_depth?
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 were
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,
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
20 matches
Mail list logo
