Re: [HACKERS] regression tests

Peter Eisentraut wrote:
>
> Once again this thought also: How about running the regression tests on a
> single user postgres backend directly? That way you don't rely on some
> obscure frontend and some client library which might change soon, too.
> Also you have more control over internals. Finally, you could easily run
> the regression tests on an uninstalled build. Think ./configure; make;
> make check; make install. Or am I way out there now?

That should have been done BEFORE messing up anything. This
hasn't been done, so I think it's the job of those who change
output formats, to provide new expected regression results
too. This hasn't been done too, and that's bad.

>
> > I see a little problem with checking if the output is still
> > O.K. too. It seems that psql now buffers all the query
> > result messages until a SELECT is done. So if the regression
> > input contains only INSERT/UPDATE/DELETE statements, all the
> > responses are at the end, not after each statement.
>
> Huh? psql doesn't buffer anything. Could you please elaborate on this
> and/or give me an example? I never heard of that one and I thought Bruce
> was a really thorough tester . . .

As I see, the result messages aren't in the (old) expected
outputs at all. But they are now. From the boolean test:

CREATE TABLE BOOLTBL1 (f1 bool);

INSERT INTO BOOLTBL1 (f1) VALUES ('t'::bool);

INSERT INTO BOOLTBL1 (f1) VALUES ('True'::bool);

INSERT INTO BOOLTBL1 (f1) VALUES ('true'::bool);

-- BOOLTBL1 should be full of true's at this point
SELECT '' AS t_3, BOOLTBL1.*;
CREATE
INSERT 18633 1
INSERT 18634 1
INSERT 18635 1
t_3 | f1
-----+----
| t
| t
| t
(3 rows)

As you can see, the CREATE and INSERT responses are printed
after the SELECT statement, just before it's own output.

Again, if someone changes things that change output, he has
to provide new expected results for the regression suite. If
the changes to psql are still a work in progress, it should
have been done on separated sources until at least the output
format is stable.

What actually happened isn't good practice (IMHO). Ask all
other developers to work around some temporary misbehaviour
that makes the entire backend development a blind flight. And
the fatal abnormal backend termination at the end of the
regression show's what this lazyness can end in. ISTM someone
has broken something and didn't notice. Thus, at least that
other one didn't do it with your mentioned workaround.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #