Re: [HACKERS] Regression test status (was type coersion)

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

Bruce Momjian wrote:

> Do any of these problems still exist?
>
> > "Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)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.