On 01/08/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
You're right. I had forgotten to do
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote:
Reini Urban [EMAIL PROTECTED] writes:
BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't find any 64-bit-int type
Adrian Maier wrote:
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote:
Reini Urban [EMAIL PROTECTED] writes:
BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is
defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
I thought about that too but it seems a very bad idea.
On 01/08/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Adrian Maier wrote:
On 20/07/06, Tom Lane [EMAIL PROTECTED] wrote:
Apparently the regression test is comparing the results/float8.out
with expected/float8-small-is-zero.out because of the following line
in
src/test/regress/resultmap :
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
I thought about that too but it seems a very bad idea. small-is-zero is
distinctly less
On 01/08/06, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe we need to abandon trying to map float8 results exactly in the
resultmap file, and just let pg_regress pick the best fit as we do with
some other tests.
I thought about that too but it seems a very
Andrew Dunstan [EMAIL PROTECTED] 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
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
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?
Would this do the trick?
cheers
andrew
Andrew Dunstan [EMAIL PROTECTED] writes:
Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
regards, tom lane
---(end of
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Would this do the trick?
I think Bruce changed the call convention for run_diff ... are you
looking at CVS tip? Otherwise it looks reasonable.
You're right. I had forgotten to do a cvs update. Fixed and committed.
cheers
Adrian Maier schrieb:
Hello,
While setting up a buildfarm installation for cygwin, I've
uncountered the following
regression failure :
float8 ... FAILED
== pgsql.3132/src/test/regress/regression.diffs
*** ./expected/float8-small-is-zero.outTue Jul 18
On 20/07/06, Reini Urban [EMAIL PROTECTED] wrote:
Thanks,
Which postgresql version?
The version is cvs HEAD.
Can we have a regular cygwin error report please mailed to cygwin at
cygwin.com please. See http://cygwin.com/problems.html (cygcheck -s -v
-r cygcheck.out)
Looks like a strtod()
Reini Urban [EMAIL PROTECTED] writes:
BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also.
You sure? INT64_IS_BUSTED should *not* be set in that case --- it's
only supposed to be set if we couldn't find any 64-bit-int type at all.
As for the regression test failure, it's
14 matches
Mail list logo
