Re: TAP output format in pg_regress

> On 10 Nov 2022, at 11:44, Nikolay Shaplov <dhyan(at)nataraj(dot)su> wrote:

> I've checked new output, if is conform TAP specification. Checked that prove
> consumes new pg_regress output well.

Great!

> Did not found quick way to include prove TAP harness right into Makefile, so I
> check dumped output, but it is not really important for now, I guess.

I think we'll start by adding TAP to the meson testrunner and await to see
where the make buildsystem ends up before doing anything there.

> As for the code, I gave it a quick readthrough... And main issue I've stumbled
> was here:

Re-reading this I realized this was actually no longer needed as the testnumber
is padded, so it's all removed. I've also refactored printing into a separate
function.

> If this patch really needs reviewer and my way of thinking is acceptable,
> please let me know, I will set myself as a reviewer and will dig further into
> the code.

Please do, reviewers are always welcome (on all patches), it's an extremely
valuable contribution to the community.

The attached contains these fixes, a small cleanups and the GCC warning on
printf attribute that Andres pointed to upthread.

The "make check" output now looks like the below, in an attempt to keep it
recognizable while still TAP compliant. fast_default is not running as part of
a parallel group, hence the different indentation.

ok 207 compression 191 ms
not ok 208 memoize 144 ms
ok 209 stats 1423 ms
# parallel group (2 tests): event_trigger oidjoins
ok 210 event_trigger 117 ms
ok 211 oidjoins 166 ms
ok 212 fast_default 143 ms
1..212
# 1 of 212 tests failed.
# The differences that caused some tests to fail can be viewed in the
# file "/Users/danielg/dev/postgresql/hacking/src/test/regress/regression.diffs". A copy of the test summary that you see
# above is saved in the file "/Users/danielg/dev/postgresql/hacking/src/test/regress/regression.out".

Patch 0002 makes meson treat the output as TAP, which makes "meson test" look
like this:

20/75 postgresql:isn / isn/regress OK 4.10s 1 subtests passed
21/75 postgresql:regress / regress/regress OK 22.73s 212 subtests passed
22/75 postgresql:intarray / intarray/regress OK 5.01s 1 subtests passed
...
73/75 postgresql:test_ddl_deparse / test_ddl_deparse/regress OK 13.18s 21 subtests passed
74/75 postgresql:test_shm_mq / test_shm_mq/regress OK 9.14s 1 subtests passed
75/75 postgresql:ecpg / ecpg/ecpg OK 23.68s 62 subtests passed

I'm not sure if that's the right way to go about configuring regress tests as
TAP emitting, but it at least shows that meson is properly parsing the output
AFAICT.

--
Daniel Gustafsson https://vmware.com/