pg_migrator to /contrib in a later 9.0 beta
in [PgSql]
|
Prev: [HACKERS] pg_migrator to /contrib in a later 9.0 beta
Next: [HACKERS] failed assertion and panic in standby mode
From: Andrew Dunstan on 1 May 2010 23:31 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. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 1 May 2010 23:32 On Sat, May 1, 2010 at 11:31 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > 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. I think that would be "good enough". But right now we can do better. No reason to rip it out, is there? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 1 May 2010 23:38 Andrew Dunstan <andrew(a)dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 1 May 2010 23:40 On Sat, May 1, 2010 at 11:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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. That might be OK if by "multiple versions" we mean "multiple branches within the repository". But I'm not so sure about having a version in the core repository and another version on pgfoundry, or something of that sort. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 1 May 2010 23:52
Robert Haas <robertmhaas(a)gmail.com> writes: > On Sat, May 1, 2010 at 11:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> 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. > That might be OK if by "multiple versions" we mean "multiple branches > within the repository". But I'm not so sure about having a version in > the core repository and another version on pgfoundry, or something of > that sort. True. If we push it into contrib as of 9.0, I think this won't be too bad, because the pgfoundry version will only be covering 8.3->8.4. Given all the limitations in that version, it's not going to be too interesting and will probably die on the vine pretty quickly. If we hold off merging it till 9.1, though, the pgfoundry version probably will be useful and in need of maintenance for a while to come. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |