Re: Alpha releases: How to tag

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Alpha releases: How to tag
Date: 2009-08-08 04:17:45
Message-ID: 533146BE-ACD5-4F7A-9F56-22EC0DE21097@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Aug 7, 2009, at 11:50 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> David Fetter wrote:
>>> 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?
>
> I have no idea what you are thinking. pg_migrator is in C just like
> the
> backend code. Do you want some plugin module to do migrations? I
> have
> neither the time or desire to implement that.

It seems that it would also negate one of the major benefits of
pg_migrator, which is that it doesn't require you to rewrite all of
your data.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2009-08-08 07:45:09 Re: WIP: to_char, support for EEEE format
Previous Message Brendan Jurd 2009-08-08 04:05:24 Re: pg_dump Add dumping of comments on index columns