Re: TAP output format in pg_regress

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>, vignesh C <vignesh21(at)gmail(dot)com>
Cc: Nikolay Shaplov <dhyan(at)nataraj(dot)su>, Andres Freund <andres(at)anarazel(dot)de>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: TAP output format in pg_regress
Date: 2023-03-15 10:36:02
Message-ID: 34735bb9-ca5e-8b3d-1ccd-c4ba252bbfa4@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24.02.23 10:49, Daniel Gustafsson wrote:
> Another rebase on top of 337903a16f. Unless there are conflicting reviews, I
> consider this patch to be done and ready for going in during the next CF.

I think this is just about as good as it's going to get, so I think we
can consider committing this soon.

A few comments along the way:

1) We can remove the gettext markers _() inside calls like note(),
bail(), etc. If we really wanted to do translation, we would do that
inside those functions (similar to errmsg() etc.).

2) There are a few fprintf(stderr, ...) calls left. Should those be
changed to something TAP-enabled?

3) Maybe these lines

+++ isolation check in src/test/isolation +++

should be changed to TAP format? Arguably, if I run "make -s check",
then everything printed should be valid TAP, right?

4) From the introduction lines

============== creating temporary instance ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 61696 with PID 85346
============== creating database "regression" ==============
============== running regression test queries ==============

you have kept

# running on port 61696 with PID 85346

which, well, is that the most interesting of those?

The first three lines (creating, initializing, starting) take some
noticeable amount of time, so they could be kept as a progress
indicator. Or just delete all of them? I suppose some explicit
indication about temp-instance versus existing instance would be useful.

5) About the output format. Obviously, this will require some
retraining of the eye. But my first impression is that there is a lot
of whitespace without any guiding lines, so to speak, horizontally or
vertically. It makes me a bit dizzy. ;-)

I think instead

# parallel group (2 tests): event_trigger oidjoins
ok 210 event_trigger 131 ms
ok 211 oidjoins 190 ms
ok 212 fast_default 158 ms
ok 213 tablespace 319 ms

Something like this would be less dizzy-making:

# parallel group (2 tests): event_trigger oidjoins
ok 210 - + event_trigger 131 ms
ok 211 - + oidjoins 190 ms
ok 212 - fast_default 158 ms
ok 213 - tablespace 319 ms

Just an idea, we don't have to get this exactly perfect right now, but
it's something to think about.

I think if 1-4 are addressed, this can be committed.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2023-03-15 10:40:00 Re: postgres_fdw: Useless if-test in GetConnection()
Previous Message Etsuro Fujita 2023-03-15 10:18:41 postgres_fdw: Useless if-test in GetConnection()