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: Mark Kirkwood on 29 Apr 2010 17:46 Bruce Momjian wrote: > > and most of the limitations of pg_migrator are gone when migrating to > 9.0, even from Postgres 8.3. This could help beta testers move their > data to 9.0 as well. > > Wouldn't this help even for beta1? Cheers Mark -- 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 29 Apr 2010 18:04 Mark Kirkwood <mark.kirkwood(a)catalyst.net.nz> writes: > Bruce Momjian wrote: >> and most of the limitations of pg_migrator are gone when migrating to >> 9.0, even from Postgres 8.3. This could help beta testers move their >> data to 9.0 as well. > Wouldn't this help even for beta1? It's too late for beta1. It probably should have been proposed when there was still time ... but it wasn't. I'm not necessarily averse to shoving it in as of beta2 or beta3 or so; we've always been laxer about contrib than the core server. 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: Bruce Momjian on 29 Apr 2010 18:04 Mark Kirkwood wrote: > Bruce Momjian wrote: > > > > and most of the limitations of pg_migrator are gone when migrating to > > 9.0, even from Postgres 8.3. This could help beta testers move their > > data to 9.0 as well. > > > > > Wouldn't this help even for beta1? It would, but there is so much work going into getting other features done that there just isn't enough time. We don't want pg_migrator delaying beta1. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- 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: Peter Eisentraut on 30 Apr 2010 02:40 On tor, 2010-04-29 at 17:34 -0400, Bruce Momjian wrote: > I talked to a few people personally about this, and it seems there was a > misunderstanding. I was not asking if pg_migrator should be in 9.0 > beta1. I was asking if we should think about putting it into a later > 9.0 beta, like 9.0 beta3. It would be another major 9.0 feature. If it's supposed to be a major feature, then it should be in src/bin, and fully integrated in the install, the documentation, etc. If you want to put it in contrib because the standards are more lax there, then by definition it's not really a major feature, it's just a random feature that was snuck in. You can't have it both ways. My personal feeling is that pg_migrator should be fully integrated, but it's too late for that, obviously. Let's do it for 9.1. I also think that the standards for contrib should not be so lax that a completely new module can be added after beta. (This is mostly informed by the feeling that contrib should go away entirely.) -- 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: Dimitri Fontaine on 30 Apr 2010 04:43
Peter Eisentraut <peter_e(a)gmx.net> writes: > My personal feeling is that pg_migrator should be fully integrated, but > it's too late for that, obviously. Let's do it for 9.1. +1 > I also think that the standards for contrib should not be so lax that a > completely new module can be added after beta. (This is mostly informed > by the feeling that contrib should go away entirely.) +1 For the record, the contrib replacement would look like proper Extension handling in dump&restore, PGXS support for windows, and PGAN for source level archive distribution. We'd still rely on distributions support for binaries. Those are the technical layers we need, then we'd have a PGAN entry for replacing contrib, and a host of other ones. The contrib Archive Network would contain -core reviewed (and maintained?) extensions, the other ones are on their own. Maybe the main other one would be (could be?) a new component of pgfoundry. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |