wieck@debis.com
>[pgsql@hot] ~/devel/src/test/regress > ./checkresults
>======   int2   ======
>10c10
>< ERROR:  pg_atoi: error reading "100000": Numerical result out of range
>---
>> ERROR:  pg_atoi: error reading "100000": Math result not representable
>======   int4   ======
>10c10
>< ERROR:  pg_atoi: error reading "1000000000000": Numerical result out of range
>---
>> ERROR:  pg_atoi: error reading "1000000000000": Math result not representable
>[pgsql@hot] ~/devel/src/test/regress >
>
>
>
>    Such a regression result while we're in the middle of feature
>    development.
>
>    I'm really impressed - if we only can keep it on this  level!
>

I'm sure we could get rid of even those errors if we were to
incorporate some test like the following and then mangle the
expected results accordingly.

Trouble is I'm not sure how portable the code is:-

SPARCLinux compiles and gives "Math result not representable"
Solaris7   compiles and gives "Result too large"

Comments?

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
int main(void)
{
        char *s = "10000000000000000000000000000000000000000000000000";
        long            l = 0;
        char       *badp = (char *) NULL;

        errno = 0;

        l = strtol(s, &badp, 10);
        if (errno) {
                printf("%s\n",strerror(errno));
                exit(0);
        } else {
                printf("Error - No Error.");
                exit(1);
        }
}  


Fri, 1 Oct 1999 20:02:54 +0100 (BST)
Keith Parks <emkxp01@mtcc.demon.co.uk>
Re: [HACKERS] PostgreSQL 6.5.2
> wieck@debis.com
> >[pgsql@hot] ~/devel/src/test/regress > ./checkresults
> >======   int2   ======
> >10c10
> >< ERROR:  pg_atoi: error reading "100000": Numerical result out of range
> >---
> >> ERROR:  pg_atoi: error reading "100000": Math result not representable
> >======   int4   ======
> >10c10
> >< ERROR:  pg_atoi: error reading "1000000000000": Numerical result out of range
> >---
> >> ERROR:  pg_atoi: error reading "1000000000000": Math result not representable
> >[pgsql@hot] ~/devel/src/test/regress >

I am inclined to strip off error messages after the second : and the do
the compare so:

	ERROR:  pg_atoi: error reading "1000000000000": Math result not representa..


becomes:

	ERROR:  pg_atoi: error reading "1000000000000":

They we just have to make sure all calls to perror have a colon before
them.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 1 Oct 1999 16:11:28 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] PostgreSQL 6.5.2
Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> I'm sure we could get rid of even those errors if we were to
> incorporate some test like the following and then mangle the
> expected results accordingly.

I don't see much value in getting rid of the discrepancies in strerror()
messages unless you have some proposal for getting rid of platform-
specific float roundoff differences.  On my machine, the diffs in the
float8 and geometry regress tests are *much* larger and much harder to
validate by eyeball than the piddling little diffs in int2 and int4.
(I suppose I should submit platform-specific expected files for HPUX,
but have never gotten round to it...)

However, if people like this approach, why not just print out
"strerror(ERANGE)" instead of fooling with strtol?

			regards, tom lane

Fri, 01 Oct 1999 17:32:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PostgreSQL 6.5.2 
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> They we just have to make sure all calls to perror have a colon before
> them.

IIRC, perror is defined to supply the colon for you.  But this approach
won't really work unless you want to guarantee that colons never appear
for any other reason in the regress outputs... horology, for one, is
going to have a problem with that...

It does seem that the majority of the platform-specific expected files
we have are for this one issue in int2/int4, so maybe Keith's idea of
substituting the correct error message as a localization string is not a
bad one.  We already have all the mechanism for that.

			regards, tom lane

Fri, 01 Oct 1999 17:38:59 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] PostgreSQL 6.5.2 