| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_migrator to /contrib in a later 9.0 beta |
| Date: | 2010-05-02 03:38:06 |
| Message-ID: | 587.1272771486@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Robert Haas wrote:
>> I don't think it's going
>> to be practical to retain all the migration code for every pair of
>> versions forever,
> I thought the idea was just to support migration from version N to
> version N+1.
Yeah. I think trying to do more than that is just going to make things
messy. For example, we added features to pg_dump and the core server
since 8.4 to help pg_migrator do its thing. Trying to make the same
pg_migrator code support cases with and without those features available
is going to complicate the code, not to mention the documentation,
enormously.
To the extent that future bug fixes are relevant to multiple versions
of pg_migrator, we could just apply them to multiple branches, same as
we manage such fixes for the core code. I don't see that trying to
have a single version of pg_migrator is going to make things easier
anywhere.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-05-02 03:40:09 | Re: pg_migrator to /contrib in a later 9.0 beta |
| Previous Message | Robert Haas | 2010-05-02 03:32:20 | Re: pg_migrator to /contrib in a later 9.0 beta |