Re: float8 regression failure (HEAD, cygwin)

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> I thought about that too but it seems a very bad idea. small-is-zero is
>> distinctly "less correct" than the regular output, and I don't think we
>> want pg_regress to be blindly accepting it as OK on any platform.

> Yes, good points. One other thought I had was that we could have
> pg_regress always allow a fallback to the canonical result file.

Hm, that's a good thought. Want to see how painful it is to code?

One thing I realized while looking at resultmap just now is that the
handmade regex matcher code I wrote for pg_regress.c (lifted from the
backend's LIKE algorithm) doesn't handle bracketed character classes,
but we've got one of those in resultmap:

float8/i.86-.*-freebsd[234]=float8-small-is-zero

Dunno how I missed that :-(. So presumably HEAD would be failing right
now on freebsd-before-5.0, if we had any of 'em in the buildfarm.

Adding char-class code to the matcher wouldn't be too hard, but it
probably wouldn't solve the cygwin problem, and as I mentioned I feel
zero allegiance to the historical format of resultmap anyway --- it
was designed the way it is purely because it was fairly easy to handle
in a few lines of shell script.

If we used your idea of always allowing a fallback to the canonical
file, then we could just make the freebsd line

float8/i.86-.*-freebsd=float8-small-is-zero

and it would do the right thing. Alternatively we could do something
more adventurous with matching to OS versions --- I'm envisioning
something roughly like

float8/i.86-.*-freebsd<5=float8-small-is-zero
float8/i.86-pc-cygwin<5.0.21=float8-small-is-zero

This would be more flexible in the long run, but might be overkill.
The fallback idea sounds like a reasonable compromise ...

regards, tom lane