Re: Alpha releases: How to tag - Mailing list pgsql-hackers

From David Fetter
Subject Re: Alpha releases: How to tag
Date
Msg-id 20090807212932.GB25552@fetter.org
Whole thread Raw
In response to Re: Alpha releases: How to tag  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Alpha releases: How to tag  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Alpha releases: How to tag  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Fri, Aug 07, 2009 at 04:07:08PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> > > David Fetter <david@fetter.org> writes:
> > > > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> > > >> And I doubt we'd bother generating pg_migrator builds that
> > > >> work for pairs of alpha releases.
> > > 
> > > > That's an interesting idea.  Shouldn't pg_migrator be mandated
> > > > to work for *any* catversion bump?
> > > 
> > > Oh, are you volunteering to make that happen?  That code is
> > > going to be ugly enough just dealing with pairs of major
> > > releases ...
> > 
> > With all due respect, if pg_migrator does not function in such a
> > way as to have data-driven composable changes, it's going to bang
> > us up in the long haul much worse than not branching alphas ever
> > could.
> > 
> > We require that people supply docs with their changes, and it is
> > totally unreasonable to let them send in catalog changes which do
> > not include need migration changes.  That's how it works in every
> > other RDBMS outfit that has changes on disk, and we do not need to
> > be the exception.
> > 
> > If pg_migrator doesn't have this ability, we need to refactor it
> > until it does, or go with something that can.
> 
> Odds are that the patch submitters will not understand enough to
> know how to modify pg_migrator, but just knowing something broke is
> usually enough for the hackers group to find a fix.

This is a pretty serious drawback.  If we're going to require that
people send migration scripts when they change the on-disk format,
this needs to be easy.  The program, whatever it turns out to be,
needs to take composable changes which people would submit along with
their patch, just as they do docs.

How much refactoring of pg_migrator would such a change take?  Would
it be worthwhile to do that, or just start a different 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


pgsql-hackers by date:

Previous
From: Neil Best
Date:
Subject: Re: [GENERAL] \copy: unexpected response (4)
Next
From: Alvaro Herrera
Date:
Subject: Re: Alpha releases: How to tag