Re: TAP output format in pg_regress
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Daniel Gustafsson <daniel@yesql.se>, Nikolay Shaplov <dhyan@nataraj.su>
Cc: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2022-11-24T19:32:35Z
Lists: pgsql-hackers
On November 24, 2022 11:07:43 AM PST, Daniel Gustafsson <daniel@yesql.se> wrote: >> On 24 Nov 2022, at 18:07, Nikolay Shaplov <dhyan@nataraj.su> wrote: >One option could be to redefine bail() to take the exit function as a parameter >and have the caller pass the preferred exit handler. > >-bail_out(bool non_rec, const char *fmt,...) >+bail(void (*exit_func)(int), const char *fmt,...) > >The callsites would then look like the below, which puts a reference to the >actual exit handler used in the code where it is called. I'd just rename _bail to bail_noatexit(). >> This magic spell "...%-5i %s%-*s %8.0f ms\n" is too dark to repeat it even two >> times. I understand problems with spaces... But may be it would be better >> somehow narrow it to one ugly print... Print "ok %-5i "|"not ok %-5i" to >> buffer first, and then have one "%s%-*s %8.0f ms%s\n" print or something like >> that... > >I'm not convinced that this printf format is that hard to read (which may well >be attributed to Stockholm Syndrome), and I do think that breaking it up and >adding more code to print the line will make it less readable instead. I don't think it's terrible either. I do think it'd also be ok to switch between ok / not ok within a single printf, making it easier to keep them in sync. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Commits
-
pg_regress: Emit TAP compliant output
- 558fff0adfa0 16.0 landed
-
Consider a failed process as a failed test in pg_regress
- 337903a16fb0 16.0 landed
-
Avoid reference to nonexistent array element in ExecInitAgg().
- 92957ed98c5c 16.0 cited