Re: CSV arm check failure

From: Marko Kreen <marko(at)l-t(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Jim Buttafuoco <jim(at)contactbda(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CSV arm check failure
Date: 2005-01-06 20:06:33
Message-ID: 20050106200633.GA10780@l-t.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 06, 2005 at 02:05:17PM -0500, Tom Lane wrote:
> Marko Kreen <marko(at)l-t(dot)ee> writes:
> > I have not looked at pg_regress much and had not noticed the
> > 'unconditional alternative' feature. I only thought of the
> > resultmap alternative. Unconditionally adding FastFPE results
> > may even be good, so that FastFPE can pass on any platform.
>
> No, it would be bad, because on most other platforms this behavior
> is probably a bug, and altering the tests like that would mask the bug.
>
> The unconditional-acceptance thing has to be used with great caution;
> preferably only for issues that we expect on many platforms (such as
> locale dependencies).

How about the following then: let pg_regress.sh accept multiple
choices from resultmap.

--
marko

Attachment Content-Type Size
arm-fastfpe.diff text/plain 11.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-01-06 20:07:57 Re: oldish libpq bug still in RC2
Previous Message Andrew Dunstan 2005-01-06 19:35:52 Re: CSV arm check failure