Andrew Dunstan <andrew@dunslane.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-zerofloat8/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