Re: [HACKERS] regression tests - Mailing list pgsql-hackers

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@debis.com (Jan Wieck) #