Peter Eisentraut píše v pá 03. 07. 2009 v 09:19 +0300: > On Friday 03 July 2009 05:16:41 Robert Haas wrote: > > On Thu, Jul 2, 2009 at 3:42 PM, Zdenek Kotala<zdenek.kot...@sun.com> wrote: > > > Josh Berkus píše v st 01. 07. 2009 v 17:21 -0700: > > >> Folks, > > >> > > >> There's been a lot of discussion/argument around how to handle the last > > >> commitfest, but there seems to be a total consensus that we want to have > > >> the first CF on July 15th. > > > > > > Can we add flags like bump catalog version, bump page layout version, > > > modify AM for each patch? It should help to track pg_upgrade changes. > > > > That's not a bad idea, and it wouldn't be hard to add various flags > > and things to the CommitFest app I wrote, but how would we maintain > > the information and keep it correct? It seems like there might be a > > danger that patch authors wouldn't know whether or not they were doing > > those things. Also, how would we handle changes by committers, who > > don't always go through the CommitFest process? > > I think this information could be computed automatically, if someone cared > enough. It shouldn't be necessary to bother every single participant in the > process with this.
I think that developer is responsible for his patch. He should know what he doing. When he will send a patch and see checkbox like "modified AM?" then he should know what he modified? It is also warning for commiter that catalog version has to be bumped during a commit. I don't see any method how to check automatically. Something could be possible - like structure checker. But when meaning of data is going to be different. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers