Thread: WITH RECURSIVE updated to CVS TIP
Folks, Please find patch enclosed, including some documentation. Can we see about getting this in this commitfest? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
hello david,
i did some quick testing with this wonderful patch.
it seems there are some flaws in there still:
test=# explain select count(*)
test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT DISTINCT n+1 FROM t )
test(# SELECT * FROM t WHERE n < 5000000000) as t
test-# WHERE n < 100;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!> \q
this one will kill the planner :(
removing the (totally stupid) distinct avoids the core dump.
i found one more issue;
-- broken: wrong result
test=# select count(*) from ( WITH RECURSIVE t(n) AS (
SELECT 1 UNION ALL SELECT n + 1 FROM t)
SELECT * FROM t WHERE n < 5000000000) as t WHERE n < (
select count(*) from ( WITH RECURSIVE t(n) AS (
SELECT 1 UNION ALL SELECT n + 1 FROM t )
SELECT * FROM t WHERE n < 5000000000) as t WHERE n < 100) ;
count
-------
1
(1 row)
if i am not totally wrong, this should give us a different result.
i am looking forward to see this patch in core :).
it is simply wonderful ...
many thanks,
hans
On Jul 3, 2008, at 1:11 AM, David Fetter wrote:
Folks,Please find patch enclosed, including some documentation.Can we see about getting this in this commitfest?Cheers,David.--David Fetter <david@fetter.org> http://fetter.org/Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetterSkype: davidfetter XMPP: david.fetter@gmail.comRemember to vote!--Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)To make changes to your subscription:
--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com
On Sat, Jul 05, 2008 at 10:43:57AM +0200, Hans-Juergen Schoenig wrote: > hello david, > > i did some quick testing with this wonderful patch. > it seems there are some flaws in there still: > > test=# explain select count(*) > test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT > DISTINCT n+1 FROM t ) > test(# SELECT * FROM t WHERE n < 5000000000) as t > test-# WHERE n < 100; > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > !> \q > > this one will kill the planner :( > removing the (totally stupid) distinct avoids the core dump. Any idea why this might be happening? > i found one more issue; > > -- broken: wrong result > test=# select count(*) from ( WITH RECURSIVE t(n) AS ( > SELECT 1 UNION ALL SELECT n + 1 FROM t) > SELECT * FROM t WHERE n < 5000000000) as t WHERE n < ( > select count(*) from ( WITH RECURSIVE t(n) AS ( > SELECT 1 UNION ALL SELECT n + 1 FROM t ) > SELECT * FROM t WHERE n < 5000000000) as t WHERE n < 100) ; > count > ------- > 1 > (1 row) > > if i am not totally wrong, this should give us a different result. What result should it give, and what do you think is going wrong here? > i am looking forward to see this patch in core :). So am I :) > it is simply wonderful ... > > many thanks, Thanks go to the kind people who actually wrote the thing. I've just been using git to keep the bit-rot off it :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Hi,
From: Hans-Juergen Schoenig <postgres@cybertec.at>
Subject: Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
Date: Sat, 5 Jul 2008 10:43:57 +0200
> i did some quick testing with this wonderful patch.
> it seems there are some flaws in there still:
>
> test=# explain select count(*)
> test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL
> SELECT DISTINCT n+1 FROM t )
> test(# SELECT * FROM t WHERE n < 5000000000) as t
> test-# WHERE n < 100;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !> \q
>
> this one will kill the planner :(
> removing the (totally stupid) distinct avoids the core dump.
Thanks. I've fixed on local repository.
> i found one more issue;
>
> -- broken: wrong result
> test=# select count(*) from ( WITH RECURSIVE t(n) AS (
> SELECT 1 UNION ALL SELECT n + 1 FROM t)
> SELECT * FROM t WHERE n < 5000000000) as t WHERE n < (
> select count(*) from ( WITH RECURSIVE t(n) AS (
> SELECT 1 UNION ALL SELECT n + 1 FROM t )
> SELECT * FROM t WHERE n < 5000000000) as t WHERE n < 100) ;
I've fixed. However, this query enters infinite loop.
WITH RECURSIVE t(n) AS (
SELECT 1 UNION ALL SELECT n + 1 FROM t)
SELECT * FROM t WHERE n < 5000000000
The planner distributed WHERE-clause into WITH-clause with previous
recursive-patch.
WITH RECURSIVE t(n) AS (
SELECT 1 WHERE n < 5000000000
UNION ALL
SELECT n + 1 FROM t WHERE n < 5000000000)
SELECT * FROM t;
This optimization is in qual_is_pushdown_safe(). So, I've fixed not to
optimize WITH-clause in the function.
Regards,
--
Yoshiyuki Asaba
y-asaba@sraoss.co.jp
>
> if i am not totally wrong, this should give us a different result.
>
> i am looking forward to see this patch in core :).
> it is simply wonderful ...
>
> many thanks,
>
> hans
>
>
>
>
>
>
> On Jul 3, 2008, at 1:11 AM, David Fetter wrote:
>
> > Folks,
> >
> > Please find patch enclosed, including some documentation.
> >
> > Can we see about getting this in this commitfest?
> >
> > Cheers,
> > David.
> > --
> > David Fetter <david@fetter.org> http://fetter.org/
> > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> > Skype: davidfetter XMPP: david.fetter@gmail.com
> >
> > Remember to vote!
> > Consider donating to Postgres: http://www.postgresql.org/about/
> > donate<recursive_query-7.patch.bz2>
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
>
>
>
> --
> Cybertec Schönig & Schönig GmbH
> PostgreSQL Solutions and Support
> Gröhrmühlgasse 26, 2700 Wiener Neustadt
> Tel: +43/1/205 10 35 / 340
> www.postgresql-support.de, www.postgresql-support.com
>
On Mon, Jul 07, 2008 at 04:22:21PM +0900, Yoshiyuki Asaba wrote: > Hi, > > > test=# explain select count(*) > > test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL > > SELECT DISTINCT n+1 FROM t ) > > test(# SELECT * FROM t WHERE n < 5000000000) as t > > test-# WHERE n < 100; > > server closed the connection unexpectedly > > This probably means the server terminated abnormally > > before or while processing the request. > > The connection to the server was lost. Attempting reset: Failed. > > !> \q > > > > this one will kill the planner :( > > removing the (totally stupid) distinct avoids the core dump. > > Thanks. I've fixed on local repository. Asaba-san, do you have a patch against CVS HEAD or against the previous one? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Here is the patches he made against CVS HEAD (as of today). According to him followings are fixed with the patches: - fix crush with DISTINCT - fix creating VIEW - fix the case when recursion plan has another recursion plan under it - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result - fix inifinit recursion with OUTER JOIN Not yet fixed: - detect certain queries those are not valid acroding to the standard - sort query names acording to the dependency - planner always estimate 0 cost for recursion plans -- Tatsuo Ishii SRA OSS, Inc. Japan > > - SQL:2008 に規定されているクエリ以外をエラーにする処理 > > - 依存関係の順番で評価するようにする仕組み > > - プランナが常にコスト 0 で見積る > > > On Mon, Jul 07, 2008 at 04:22:21PM +0900, Yoshiyuki Asaba wrote: > > Hi, > > > > > test=# explain select count(*) > > > test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL > > > SELECT DISTINCT n+1 FROM t ) > > > test(# SELECT * FROM t WHERE n < 5000000000) as t > > > test-# WHERE n < 100; > > > server closed the connection unexpectedly > > > This probably means the server terminated abnormally > > > before or while processing the request. > > > The connection to the server was lost. Attempting reset: Failed. > > > !> \q > > > > > > this one will kill the planner :( > > > removing the (totally stupid) distinct avoids the core dump. > > > > Thanks. I've fixed on local repository. > > Asaba-san, do you have a patch against CVS HEAD or against the > previous one? > > Cheers, > David. > -- > David Fetter <david@fetter.org> http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: david.fetter@gmail.com > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > Here is the patches he made against CVS HEAD (as of today). The git repository should now match this :) http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary Apparently, it's easiest to clone via the following URL: http://git.postgresql.org/git/~davidfetter/postgresql/.git Is there some git repository I can pull from to make this a little less manual? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter wrote: > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > > Here is the patches he made against CVS HEAD (as of today). > > The git repository should now match this :) > > http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary > > Apparently, it's easiest to clone via the following URL: > > http://git.postgresql.org/git/~davidfetter/postgresql/.git > > Is there some git repository I can pull from to make this a little > less manual? In fact, I fail to see the point of you providing the repo if the upstream guys are apparently not using it ... -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote: > David Fetter wrote: > > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > > > Here is the patches he made against CVS HEAD (as of today). > > > > The git repository should now match this :) > > > > http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=summary > > > > Apparently, it's easiest to clone via the following URL: > > > > http://git.postgresql.org/git/~davidfetter/postgresql/.git > > > > Is there some git repository I can pull from to make this a little > > less manual? > > In fact, I fail to see the point of you providing the repo if the > upstream guys are apparently not using it ... It's *very* early days to be dismissing git entirely. We don't have auths fixed up yet, and I contend that that's because the people who have sudo on the git machine are unwilling to create git-shell accounts for people who need them. If I get sudo access, I'll be delighted to do that stuff. There's another issue people seem to keep trying to sneak into this discussion, which is creating a high-value target for attackers, aka single sign-on. We really need to have a separate discussion of single sign-on and not hold up every infrastructure project while waiting for a feature that it is far from clear that we should even have in the first place. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
* David Fetter <david@fetter.org> [080709 14:45]:
> On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote:
> > In fact, I fail to see the point of you providing the repo if the
> > upstream guys are apparently not using it ...
>
> It's *very* early days to be dismissing git entirely. We don't have
> auths fixed up yet, and I contend that that's because the people who
> have sudo on the git machine are unwilling to create git-shell
> accounts for people who need them.
I don't think that was intended to dismiss git entirely, but only
question what the point of this particular git repo/branch is for:
http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=shortlog;h=with_recursive
Is it just to provide an alternative way to fetch the patch? I would
have thought that anybody who can compile PostgreSQL from source can
apply a patch (if the patch available and applies cleanly).
The with_recursive branch doesn't seem to provide any of the nice
goodies that git could provide (i.e. patch history, merge corresponding
to various versions so you can easily see what changed, etc)
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Attachment
On Wed, Jul 09, 2008 at 04:43:27PM -0400, Aidan Van Dyk wrote: > * David Fetter <david@fetter.org> [080709 14:45]: > > On Tue, Jul 08, 2008 at 09:28:34PM -0400, Alvaro Herrera wrote: > > > > In fact, I fail to see the point of you providing the repo if > > > the upstream guys are apparently not using it ... > > > > It's *very* early days to be dismissing git entirely. We don't > > have auths fixed up yet, and I contend that that's because the > > people who have sudo on the git machine are unwilling to create > > git-shell accounts for people who need them. > > I don't think that was intended to dismiss git entirely, but only > question what the point of this particular git repo/branch is for: > http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=shortlog;h=with_recursive > > Is it just to provide an alternative way to fetch the patch? I > would have thought that anybody who can compile PostgreSQL from > source can apply a patch (if the patch available and applies > cleanly). > > The with_recursive branch doesn't seem to provide any of the nice > goodies that git could provide (i.e. patch history, merge > corresponding to various versions so you can easily see what > changed, etc) I'm really new to this git thing, but I now have access to create git-shell accounts, etc. on git.postgresql.org. Any ideas you can offer on how better to handle this would really help me. :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > Here is the patches he made against CVS HEAD (as of today). > > According to him followings are fixed with the patches: > > - fix crush with DISTINCT > - fix creating VIEW > - fix the case when recursion plan has another recursion plan under it > - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result > - fix inifinit recursion with OUTER JOIN Great! I've patched psql for some partial support of WITH [RECURSIVE]. http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793 > Not yet fixed: > > - detect certain queries those are not valid acroding to the standard > - sort query names acording to the dependency Is there something in the standard on how to do this? How to sort the nodes other ways? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
> On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > > Here is the patches he made against CVS HEAD (as of today). > > > > According to him followings are fixed with the patches: > > > > - fix crush with DISTINCT > > - fix creating VIEW > > - fix the case when recursion plan has another recursion plan under it > > - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result > > - fix inifinit recursion with OUTER JOIN > > Great! > > I've patched psql for some partial support of WITH [RECURSIVE]. > > http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793 Thanks. I will incorporate them with propsed patches. > > Not yet fixed: > > > > - detect certain queries those are not valid acroding to the standard > > - sort query names acording to the dependency > > Is there something in the standard on how to do this? How to sort the > nodes other ways? No idea. What do you think if we allow only one query name at the moment. I guess most WITH RECURISVE use cases are enough with single query name. -- Tatsuo Ishii SRA OSS, Inc. Japan
On Wed, Jul 16, 2008 at 09:37:25AM +0900, Tatsuo Ishii wrote: > > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > > > Here is the patches he made against CVS HEAD (as of today). > > > > > > According to him followings are fixed with the patches: > > > > > > - fix crush with DISTINCT > > > - fix creating VIEW > > > - fix the case when recursion plan has another recursion plan under it > > > - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result > > > - fix inifinit recursion with OUTER JOIN > > > > Great! > > > > I've patched psql for some partial support of WITH [RECURSIVE]. > > > > http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793 > > Thanks. I will incorporate them with propsed patches. Part of the point of this exercise is to make git the way to do this. Can you please point me to a git repository where your latest changes are so I can publish them? > > > Not yet fixed: > > > > > > - detect certain queries those are not valid acroding to the standard > > > - sort query names acording to the dependency > > > > Is there something in the standard on how to do this? How to sort > > the nodes other ways? > > No idea. What do you think if we allow only one query name at the > moment. I'm not sure I understand what that has to do with sorting. Please find attached a place where I've found some problems sorting by tree by array as Asaba-san suggested. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
> On Wed, Jul 16, 2008 at 09:37:25AM +0900, Tatsuo Ishii wrote: > > > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote: > > > > Here is the patches he made against CVS HEAD (as of today). > > > > > > > > According to him followings are fixed with the patches: > > > > > > > > - fix crush with DISTINCT > > > > - fix creating VIEW > > > > - fix the case when recursion plan has another recursion plan under it > > > > - fix WITH RECURSIVE ...(..) SELECT ...WHERE.. returns wrong result > > > > - fix inifinit recursion with OUTER JOIN > > > > > > Great! > > > > > > I've patched psql for some partial support of WITH [RECURSIVE]. > > > > > > http://git.postgresql.org/?p=~davidfetter/postgresql/.git;a=commit;h=da63f9a82b9e902b5542f788b2e6e6bc95221793 > > > > Thanks. I will incorporate them with propsed patches. > > Part of the point of this exercise is to make git the way to do this. > Can you please point me to a git repository where your latest changes > are so I can publish them? > > > > > Not yet fixed: > > > > > > > > - detect certain queries those are not valid acroding to the standard > > > > - sort query names acording to the dependency > > > > > > Is there something in the standard on how to do this? How to sort > > > the nodes other ways? > > > > No idea. What do you think if we allow only one query name at the > > moment. > > I'm not sure I understand what that has to do with sorting. > > Please find attached a place where I've found some problems sorting by > tree by array as Asaba-san suggested. Humm. your problem seems to do nothing with the problem I refer to. What I have in my mind is something like: WITH RECURSIVE foo(a, b) AS (SELECT ... UNION SELECT...), bar(c, d) AS (SELECT ... FROM foo WHERE ...UNION...) ) SELECT * FROM foo; In this there are two query names (foo, bar) and we need to detect the dependency that bar relies on foo before processing the query. However, as I said earlier, this kind of use case would be rare in the real world, and I'd like to limit ourselves to having only one query name at the moment. Also I suggest to concentrate on reviewing the WITH RECURSIVE implementation itself now, rather than discussing how to use git repository or how to write an interesting WITH RECURSIVE applications. Don't get me wrong. I believe git is a great tool. But we have limited time and need to think about the priority. -- Tatsuo Ishii SRA OSS, Inc. Japan
On Wed, Jul 16, 2008 at 01:57:04PM +0900, Tatsuo Ishii wrote: > > > No idea. What do you think if we allow only one query name at the > > > moment. > > > > I'm not sure I understand what that has to do with sorting. > > > > Please find attached a place where I've found some problems sorting by > > tree by array as Asaba-san suggested. > > Humm. your problem seems to do nothing with the problem I refer to. Sorry about that. Is my problem reproducible? Is there maybe some way to include regression tests around it? > What I have in my mind is something like: > > WITH RECURSIVE foo(a, b) AS > (SELECT ... UNION SELECT...), > > bar(c, d) AS > (SELECT ... FROM foo WHERE ...UNION...) > ) > SELECT * FROM foo; > > In this there are two query names (foo, bar) and we need to detect the > dependency that bar relies on foo before processing the query. I think mutually recursive queries may have been dropped from SQL:2008. > However, as I said earlier, this kind of use case would be rare in > the real world, and I'd like to limit ourselves to having only one > query name at the moment. > > Also I suggest to concentrate on reviewing the WITH RECURSIVE > implementation itself now, rather than discussing how to use git > repository or how to write an interesting WITH RECURSIVE > applications. > > Don't get me wrong. I believe git is a great tool. But we have > limited time and need to think about the priority. Fair enough :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
> On Wed, Jul 16, 2008 at 01:57:04PM +0900, Tatsuo Ishii wrote: > > > > No idea. What do you think if we allow only one query name at the > > > > moment. > > > > > > I'm not sure I understand what that has to do with sorting. > > > > > > Please find attached a place where I've found some problems sorting by > > > tree by array as Asaba-san suggested. > > > > Humm. your problem seems to do nothing with the problem I refer to. > > Sorry about that. Is my problem reproducible? Is there maybe some > way to include regression tests around it? According to Asaba, it's not a bug with recursive query. In another word, the query result you are getting is the expected one. Asaba? > > What I have in my mind is something like: > > > > WITH RECURSIVE foo(a, b) AS > > (SELECT ... UNION SELECT...), > > > > bar(c, d) AS > > (SELECT ... FROM foo WHERE ...UNION...) > > ) > > SELECT * FROM foo; > > > > In this there are two query names (foo, bar) and we need to detect the > > dependency that bar relies on foo before processing the query. > > I think mutually recursive queries may have been dropped from > SQL:2008. I'm pretty sure that SQL:2008 has mutually recursive queries(I have the final draft of SQL:2008 here). > > However, as I said earlier, this kind of use case would be rare in > > the real world, and I'd like to limit ourselves to having only one > > query name at the moment. > > > > Also I suggest to concentrate on reviewing the WITH RECURSIVE > > implementation itself now, rather than discussing how to use git > > repository or how to write an interesting WITH RECURSIVE > > applications. > > > > Don't get me wrong. I believe git is a great tool. But we have > > limited time and need to think about the priority. > > Fair enough :) > > Cheers, > David. > -- > David Fetter <david@fetter.org> http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: david.fetter@gmail.com > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate