X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (neptune.hub.org [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id D63F8D1B8BF for ; Fri, 21 Nov 2003 13:04:32 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 71197-08 for ; Fri, 21 Nov 2003 09:04:04 -0400 (AST) Received: from sunsite.dcc.uchile.cl (sunsite.dcc.uchile.cl [192.80.24.2]) by svr1.postgresql.org (Postfix) with ESMTP id EE1D8D1D5FD for ; Fri, 21 Nov 2003 09:03:59 -0400 (AST) Received: from alvherre@anakena.dcc.uchile.cl [192.80.24.3] by sunsite.dcc.uchile.cl (8.8.5/Main-DCCV8-Jo6) id KAA14753; Fri, 21 Nov 2003 10:04:01 -0300 (CDT) Received: from alvherre@localhost by anakena.dcc.uchile.cl (8.8.5/MainSec-DCCV8-Jo5) id KAA06898; Fri, 21 Nov 2003 10:03:59 -0300 (CLST) Date: Fri, 21 Nov 2003 10:03:59 -0300 From: Alvaro Herrera To: Christopher Kings-Lynne Cc: Tom Lane , Jan Wieck , Peter Eisentraut , PostgreSQL Development Subject: Re: Release cycle length Message-ID: <20031121130359.GE26392@dcc.uchile.cl> References: <20031117202346.M731@ganymede.hub.org> <3FBB7F20.8050005@Yahoo.com> <6400.1069359578@sss.pgh.pa.us> <3FBD6CAA.7040500@familyhealth.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBD6CAA.7040500@familyhealth.com.au> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/1176 X-Sequence-Number: 47464 On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote: > >Yeah, I think the main issue in all this is that for real production > >sites, upgrading Postgres across major releases is *painful*. We have > >to find a solution to that before it makes sense to speed up the > >major-release cycle. > > Well, I think one of the simplest is to do a topological sort of objects > in pg_dump (between object classes that need it), AND regression > testing for pg_dump :) One of the most complex would be to avoid the need of pg_dump for upgrades ... -- Alvaro Herrera () "I call it GNU/Linux. Except the GNU/ is silent." (Ben Reiter)