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
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.
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
At 2008-07-09 17:06:19 -0700, david@fetter.org wrote: > > 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. :) The question is: what is your objective in providing this repository? I've only just cloned your repository, so I can only guess at how it is managed, but you seem to be rebasing your changes on top of the current Postgres source and responding to upstream changes by throwing away the old patches and applying the new ones. (By the way, your origin/master appears to be lagging the current HEAD by 71 commits, i.e. a month.) That has several problems: - There is no indication of how the WITH RECURSIVE patches have changed over time or in response to feedback. For example,the bugs recently fixed are indistinguishable from earlier changes. This would be very valuable information to haveduring review (and that's really what I was expecting when I cloned). - One has to clone a 250MB repository (over HTTP, with almost no progress indication) to see what is essentially exactlythe same as the posted patch. - Rebasing isn't appropriate for a public branch, since you're rewriting history that people have pulled already. If your objective is only to make an up-to-date patch always available, then it is unnecessary to publicise your repository. You could just use git-rebase to stay abreast of significant changes in origin/master and run git-format-patch to generate a patch... but then you still end up with essentially the same thing that Tatsuo Ishii posted to the list the other day anyway. I agree with Alvaro. If the developers aren't committing to this repository that the patches are generated from, there's really no point to using the repository for review. It's very much simpler to just read the patch as posted to the list. The only real benefit to review that I can imagine would be if full change history were available, which it could do if a) changes were committed separately with proper comments and b) if the branch were *NOT* rebased, but instead periodically merged with origin/master. That way I could pull from the repository and run e.g. "git-log --stat origin/master..with-recursive" or similar. Hope this helps. -- ams
"Abhijit Menon-Sen" <ams@oryx.com> writes: > The only real benefit to review that I can imagine would be if full > change history were available, which it could do if a) changes were > committed separately with proper comments and b) if the branch were > *NOT* rebased, but instead periodically merged with origin/master. > > That way I could pull from the repository and run e.g. > "git-log --stat origin/master..with-recursive" or similar. Additionally if other people could commit change patches to the repository or submit patches which upstream could apply then git would be able to update submitters trees with just the patches they're missing (ie, skipping the patches they submitted upstream or merging them cleanly) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
On Thu, Jul 10, 2008 at 04:12:34PM +0530, Abhijit Menon-Sen wrote: > At 2008-07-09 17:06:19 -0700, david@fetter.org wrote: > > > > 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. :) > > The question is: what is your objective in providing this repository? Here are my objectives: 1. Make a repository that keeps up with CVS HEAD. 2. Allow people who are not currently committers on CVS HEAD to make needed changes. > I've only just cloned your repository, so I can only guess at how it > is managed, but you seem to be rebasing your changes on top of the > current Postgres source and responding to upstream changes by > throwing away the old patches and applying the new ones. (By the > way, your origin/master appears to be lagging the current HEAD by 71 > commits, i.e. a month.) If you know a better way to do this, I'm all ears :) I'm completely new to git and pretty fuzzy on CVS. > If your objective is only to make an up-to-date patch always > available, then it is unnecessary to publicise your repository. You > could just use git-rebase to stay abreast of significant changes in > origin/master and run git-format-patch to generate a patch... but > then you still end up with essentially the same thing that Tatsuo > Ishii posted to the list the other day anyway. > > I agree with Alvaro. If the developers aren't committing to this > repository that the patches are generated from, there's really no > point to using the repository for review. It's very much simpler to > just read the patch as posted to the list. They aren't committing, at least in part, because they did not have any way to do so. I'm fixing things so that they do by creating git-shell accounts on git.postgresql.org which will have write access to that repository. To get such an account, please send me your public key and preferred user name so I can move forward on this. > The only real benefit to review that I can imagine would be if full > change history were available, which it could do if a) changes were > committed separately with proper comments and b) if the branch were > *NOT* rebased, but instead periodically merged with origin/master. Great idea! I'd be happy to wipe this repository and start over just as you propose. It would be even nicer if we can put together a standard procedure for new patches. Would you be willing to write it up? > That way I could pull from the repository and run e.g. > "git-log --stat origin/master..with-recursive" or similar. Excellent :) > Hope this helps. It does indeed. 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> [080710 10:19]: > > The question is: what is your objective in providing this repository? > > Here are my objectives: > > 1. Make a repository that keeps up with CVS HEAD. There are already at least 2 public ones that do:git://repo.or.cz/PostgreSQL.gitgit.postgresql.org (which seems to work beston http only!?!?!) > 2. Allow people who are not currently committers on CVS HEAD to make > needed changes. Uh, the point of git is it's distributed, so you don't need to be involved for them to do that.... > If you know a better way to do this, I'm all ears :) I'm completely > new to git and pretty fuzzy on CVS. Well, if you want to use git to it's fullest extent, you really need to unlearn *all* of the ideas and restrictions your fuzzy CVS knowledge is handcuffing you with. Or at least be able to stuff it in a box in some dark recess of your brain, so as to not let it control the way you try and use Git. Git is *inherently* distributed. And it's *only* a "Content tracker". Because of this, it works spectacularly well as 2 quite different tools: 1) A developer tool to manage their ideas, developments, and code (track) 2) A content distribution tool (publish) > They aren't committing, at least in part, because they did not have > any way to do so. I'm fixing things so that they do by creating > git-shell accounts on git.postgresql.org which will have write access > to that repository. Committing in GIT has *nothing* to do with an account on git.postgresql.org. It's a local operation, and if they are using git already, they can publish any number of places. And If they aren't using git already, then a git-shell account, or some special single repo on git.postgresql.org isn't going to change that. You seem to be trying to setup git as a "centralized" distribution tool (#2 above), without it being used as a developer tool (#1). I really don't see the point of that. The only difference from CVS that use will provide is you can provide CVS+patch "easily". But anybody who's going to use git to get CVS+patch already has git, and thus has CVS+patch locally available in 1 command anyways... I think Git's use as #1 *has* to come first. And, because of it's inherently distributed nature, #2 "just happens" once people are using it... a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Aidan Van Dyk wrote: > * David Fetter <david@fetter.org> [080710 10:19]: > > 2. Allow people who are not currently committers on CVS HEAD to make > > needed changes. > > Uh, the point of git is it's distributed, so you don't need to be > involved for them to do that.... Yep. People can already clone the master Pg trunk, and start from there to build patches. If they use their *private* repos for this, awesome -- they have complete history. If they want other developers to chime in with further patches, they just need to publish their repos, and let other clone them. Then, they can pull from those other repos, or allow others to push. If you want to keep updating to trunk as it moves forward, I guess you'd need to propagate the changes from trunk to your RECURSIVE repo. And if upstream changes the patch to fix some bug, you really need that bugfix to show as a separate (and probably very small) patch. Unapplying the patch and applying it back seems the worst way to proceed. Like Aidan, I think that trying to centralize the GIT repo is trying to circumvent GIT's design ideas rather than working with them. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Thu, Jul 10, 2008 at 11:31:00AM -0400, Alvaro Herrera wrote: > Aidan Van Dyk wrote: > > * David Fetter <david@fetter.org> [080710 10:19]: > > > > 2. Allow people who are not currently committers on CVS HEAD to > > > make needed changes. > > > > Uh, the point of git is it's distributed, so you don't need to be > > involved for them to do that.... > > Yep. People can already clone the master Pg trunk, and start from > there to build patches. If they use their *private* repos for this, > awesome -- they have complete history. If they want other > developers to chime in with further patches, they just need to > publish their repos, Publishing those repos is easiest on git.postgresql.org. > and let other clone them. Then, they can pull from those other > repos, or allow others to push. Again, git.postgresql.org is good for this and other places are not for reasons I've mentioned before. > If you want to keep updating to trunk as it moves forward, I guess > you'd need to propagate the changes from trunk to your RECURSIVE > repo. And if upstream changes the patch to fix some bug, you really > need that bugfix to show as a separate (and probably very small) > patch. > > Unapplying the patch and applying it back seems the worst way to > proceed. Fine. I proceeded in ignorance and will fix. I'm more than delighted to start the whole thing over based on this. > Like Aidan, I think that trying to centralize the GIT repo is trying to > circumvent GIT's design ideas rather than working with them. It's not about centralizing, but about letting a bunch of people publish their changes to the same spot without being committers on the Postgres project. 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> [080710 11:34]: > > Yep. People can already clone the master Pg trunk, and start from > > there to build patches. If they use their *private* repos for this, > > awesome -- they have complete history. If they want other > > developers to chime in with further patches, they just need to > > publish their repos, > > Publishing those repos is easiest on git.postgresql.org. Obviously not, but let's hope that the current situation changes ;-) But that has nothing to do with the original "point of this repo" question WRT the recursive patch. > > and let other clone them. Then, they can pull from those other > > repos, or allow others to push. > > Again, git.postgresql.org is good for this and other places are not > for reasons I've mentioned before. And I've not been convinced by them before either ;-) > It's not about centralizing, but about letting a bunch of people > publish their changes to the same spot without being committers on the > Postgres project. But thank's to GIT, that "same spot" is irrelevant ;-) I do think that git.postgresql.org can have value. But I think it's value is directly related (or more correctly *derived*) from the work that's happening by developers *using* git, and the use of git for development is a necessary prerequisite for publishing that development. They don't even have to be publishing to git.postgresql.org for git.postgresql.org to benefit form that development (because git is distributed)! If development isn't happening with git, and git.postgresql.org is only a set of mirrors of CVS+patches, then I don't see *any* value of git.postgresql.org. I'm pretty confident that git.postgresql.org won't *remain* valueless, because I'm pretty confident that git really is a tool that many developers will come to use... But if you're new to git, *I* think your time would be better spent doing actual development using git than trying to "manage" git repositories and just mirror CVS+patches. As you learn GIT, tracking CVS+patches will be something you pretty much "just do", and forget your actually doing. Publishing repos will also become something you "just do" and forget your actually doing.... But I really do think you need to worry about *using* git before you worry about *publishing* with git, especially if you're new to git, and have have fuzzy ideas about CVS still as your idea/framework for that publishing ;-) But all that's only my opinion, so take it with a grain of salt, or another pint ;-) a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
At 2008-07-10 07:18:28 -0700, david@fetter.org wrote: > > Here are my objectives: > > 1. Make a repository that keeps up with CVS HEAD. > > 2. Allow people who are not currently committers on CVS HEAD to > make needed changes. OK. Then, to begin with, I think it is very important to make the repository available via the git protocol. HTTP just won't cut it. > It would be even nicer if we can put together a standard procedure > for new patches. Would you be willing to write it up? The standard procedure for new patches would be the standard procedure for *any* patches when you use git. You have a branch that tracks the upstream (by which I mean the Postgres source) and a branch where you work (apply individual changes), and you merge with the origin every now and then (either in your working branch or in another branch). And once you've published a branch, you try never to rebase it. The "apply individual changes" part could be done by hand (git-apply, git-commit), or by accepting individual patches via email (git-am) or pulling from a remote repository, or by having others push into your repository. It doesn't matter. > Again, git.postgresql.org is good for this and other places are not > for reasons I've mentioned before. I haven't seen your reasons, but frankly, I would be suspicious of them even if git.postgresql.org filled me with confidence, which it doesn't. It seems to lag some way behind CVS and, as Alvaro pointed out earlier, may be missing some patches. (I realise those might have been teething troubles, and it may even be fixed now, but I just use the mirror on repo.or.cz instead.) -- ams
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