From: | Michael Meskes <meskes(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Joachim Wieland <joe(at)mcknight(dot)de>, Michael Meskes <meskes(at)postgresql(dot)org>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Stamp major release 8.3.0, |
Date: | 2007-01-11 07:41:24 |
Message-ID: | 20070111074124.GA20584@feivel.credativ.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 10, 2007 at 11:31:41PM -0500, Tom Lane wrote:
> While I can't say whether Joachim's patch is the cleanest way, surely
> we will not condemn ourselves to fixing this manually in every future
> release cycle.
I couldn't agree more. The reason why I haven't committed Joachim's
patch yet is that I'd like to bring all regression specific changes to
one place. Right now we have one change to the log file before diff'ing,
one environment variable set and a command line option.
The easiest way would be to just change the log files. This guarantees
that regression ecpg behaves exactly as the productive one. However,
this might get ugly quickly.
I will have a closer look at this as soon as my time permits.
> While I'm whining ... we really need some support in the ecpg regression
> tests for platform-specific diffs, so that the consistent ECPG-check
> failures in buildfarm can go away.
Hmm, I thought there was. Joachim, could you comment?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2007-01-11 07:42:40 | Re: [COMMITTERS] pgsql: Stamp major release 8.3.0, |
Previous Message | Richard Huxton | 2007-01-11 07:37:20 | Re: PANIC: block 463 unfound during REDO after out of |