Re: [HACKERS] Regression test status (was type coersion) - Mailing list pgsql-hackers

I check  two these of these problems.    Read ahead  --->

Bruce Momjian wrote:

> Do any of these problems still exist?
>
> > "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> > > ... all of the
> > > regression tests pass, except for the select_view test, which has been
> > > core dumping for weeks. Anyone else seeing that, or is it just me? :(
> >
> > I rebuilt the system from current sources today, and ran the regression
> > tests for the first time in a long time.  select_views works fine for
> > me, but there are several other tests that look badly broken:
> > SELECT ... ORDER BY upper(c) is misordering the results in select_implicit,
> > GROUP BY on a datetime is not working right in select_having, and the
> > random test is failing because it "can't look up operator 713".
> >
> > I'm on HP-UX 9.03, PA-RISC 1.1, gcc 2.7.2.2 if that helps.
> >
> >                       regards, tom lane
> >
> >
> > *** expected/select_implicit.out      Sat Aug 15 11:56:03 1998
> > --- results/select_implicit.out       Sat Aug 15 13:44:16 1998
> > ***************
> > *** 213,226 ****
> >   QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
> >   a
> >   -
> > - 1
> >   2
> >   3
> >   4
> >   5
> >   6
> > - 7
> >   8
> >   9
> >   0
> >   (10 rows)
> > --- 213,226 ----
> >   QUERY: SELECT a FROM test_missing_target ORDER BY upper(c);
> >   a
> >   -
> >   2
> > + 1
> >   3
> >   4
> >   5
> >   6
> >   8
> > + 7
> >   9
> >   0
> >   (10 rows)
> >
> > ----------------------
> >

Both sort orders are correct.     I seems that different machines are resolving
equivalent strings differently.    I got the same result as Tom on an RS/6000
box.   I could be an big vs little endian, signed vs unsigned chars issue.  In
any case, the actual sort order is indeterminate.  Therefore I will submit a new
regression test with reliable test data.

> > *** expected/select_having.out        Wed Jul  8 10:29:09 1998
> > --- results/select_having.out Sat Aug 15 13:44:16 1998
> > ***************
> > *** 2,12 ****
> >     GROUP BY d1 HAVING count(*) > 1;
> >   d1                          |count
> >   ----------------------------+-----
> > ! Thu Jun 13 00:00:00 1957 PDT|    2
> > ! Mon Feb 10 09:32:01 1997 PST|    3
> > ! Mon Feb 10 17:32:01 1997 PST|   13
> >   Sun Feb 16 17:32:01 1997 PST|    2
> >   Sat Mar 01 17:32:01 1997 PST|    2
> > ! invalid                     |    2
> > ! (6 rows)
> >
> > --- 2,13 ----
> >     GROUP BY d1 HAVING count(*) > 1;
> >   d1                          |count
> >   ----------------------------+-----
> > ! Thu Jun 13 00:00:00 1957 PST|    2
> > ! Mon Feb 10 17:32:01 1997 PST|    4
> > ! Mon Feb 10 09:32:01 1997 PST|    2
> > ! Mon Feb 10 17:32:01 1997 PST|    2
> > ! Mon Feb 10 17:32:01 1997 PST|    7
> >   Sun Feb 16 17:32:01 1997 PST|    2
> >   Sat Mar 01 17:32:01 1997 PST|    2
> > ! (7 rows)
> >
> >
> > ----------------------
> >

These results are also correct.  Somewhat.    I do not know much about datatime
porting issues, but if  I do a:
    SELECT d1 FROM  DATETIME_TBL
I get time reported to the 1/100 of a second.    If  GROUP BY d1 the hundredths
are not shown.   Thus, the counts and groupings are correct.   Its just not
showing the hundredths portion.

> > *** expected/random.out       Tue Apr 29 10:23:40 1997
> > --- results/random.out        Sat Aug 15 13:44:19 1998
> > ***************
> > *** 5,18 ****
> >   (1 row)
> >
> >   QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
> > ! count
> > ! -----
> > !    92
> > ! (1 row)
> >
> >   QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
> > ! count
> > ! -----
> > !    98
> > ! (1 row)
> >
> > --- 5,12 ----
> >   (1 row)
> >
> >   QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
> > ! ERROR:  can't look up operator 713
> >
> >   QUERY: SELECT count(*) FROM onek where oidrand(onek.oid, 10);
> > ! ERROR:  can't look up operator 713
> >
> >

Don't know about this one.