Received: from biology.nmsu.edu (biology.NMSU.Edu [128.123.5.72]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA47033 for ; Mon, 11 Oct 1999 14:06:06 -0400 (EDT) (envelope-from brook@biology.nmsu.edu) Received: (from brook@localhost) by biology.nmsu.edu (8.8.8/8.8.8) id MAA18307; Mon, 11 Oct 1999 12:05:42 -0600 (MDT) Date: Mon, 11 Oct 1999 12:05:42 -0600 (MDT) Message-Id: <199910111805.MAA18307@biology.nmsu.edu> X-Authentication-Warning: biology.nmsu.edu: brook set sender to brook@biology.nmsu.edu using -f From: Brook Milligan To: maillist@candle.pha.pa.us CC: vev@michvhf.com, pgsql-hackers@postgreSQL.org In-reply-to: <199910111705.NAA05903@candle.pha.pa.us> (message from Bruce Momjian on Mon, 11 Oct 1999 13:05:24 -0400 (EDT)) Subject: Re: [HACKERS] Next release is 7.0(?) References: <199910111705.NAA05903@candle.pha.pa.us> > Would this also be a relevant time to get a regression test to run on > a non-installed system? Couldn't this be done by starting up the > database on a different port from within the newly compiled source > tree for the purpose of testing? Gee, I never even though of that. What advantage would there be for that? Wouldn't that be useful for developing/debugging/testing a new version on a machine that runs some other version in production mode? One example would be someone who wants to update, but wishes to verify the functioning of the new version prior to blowing away the old one. So, one could build the new version, run regression tests, resolve any issues, THEN deinstall the old version and install the new already verified one. Another example is that developers could use a production machine to tweak new code without having to actually install the test versions. I'm sure other applications of that flexibility are apparent also. Cheers, Brook