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
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 |