WITH RECURSIVE updated to CVS TIP

[David Fetter]

Folks,

Please find patch enclosed, including some documentation.

Can we see about getting this in this commitfest?

Cheers,
David.
--
David Fetter <david@...> http://fetter.org/
Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@...

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate



--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Hans-Juergen Schoenig-2]

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@...> http://fetter.org/

Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter

Skype: davidfetter      XMPP: david.fetter@...

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@...)

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: [phone] / 340

www.postgresql-support.de, www.postgresql-support.com

[David Fetter]

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@...> http://fetter.org/
Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@...

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Yoshiyuki Asaba-2]

Hi,

From: Hans-Juergen Schoenig <postgres@...>
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@...

>
> 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@...> http://fetter.org/
> > Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
> > Skype: davidfetter      XMPP: david.fetter@...
> >
> > 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@...)
> > 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: [phone] / 340
> www.postgresql-support.de, www.postgresql-support.com
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[David Fetter]

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@...> http://fetter.org/
Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@...

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tatsuo Ishii-4]

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@...> http://fetter.org/
> Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
> Skype: davidfetter      XMPP: david.fetter@...
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[David Fetter]

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@...> http://fetter.org/
Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@...

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Alvaro Herrera-7]

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[David Fetter]

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@...> http://fetter.org/
Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@...

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Aidan Van Dyk-2]

* David Fetter <david@...> [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@...                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

[David Fetter]

On Wed, Jul 09, 2008 at 04:43:27PM -0400, Aidan Van Dyk wrote:

> * David Fetter <david@...> [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@...> http://fetter.org/
Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@...

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Abhijit Menon-Sen]

At 2008-07-09 17:06:19 -0700, david@... 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 have during 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 exactly the 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Gregory Stark]

"Abhijit Menon-Sen" <ams@...> 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's PostgreSQL training!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[David Fetter]

On Thu, Jul 10, 2008 at 04:12:34PM +0530, Abhijit Menon-Sen wrote:
> At 2008-07-09 17:06:19 -0700, david@... 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@...> http://fetter.org/
Phone: [phone]  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@...

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Aidan Van Dyk-2]

* David Fetter <david@...> [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.git
        git.postgresql.org (which seems to work best on 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@...                                       command like a king,
http://www.highrise.ca/                                   work like a slave.