Re: TAP output format in pg_regress

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: TAP output format in pg_regress
Дата
Msg-id 0F8DA66F-3604-4ED4-B2EE-57815652449C@yesql.se
обсуждение исходный текст
Ответ на Re: TAP output format in pg_regress  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> On 4 Jul 2022, at 16:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> I'm not sure what to make of all these options.  I think providing a TAP
>> output for pg_regress is a good idea.  But then do we still need the old
>> output?  Is it worth maintaining two output formats that display exactly
>> the same thing in slightly different ways?
>
> Probably is, because this is bad:
>
>> ... The proposed default format now hides the
>> fact that some tests are started in parallel.  I remember the last time
>> I wanted to tweak the output of the parallel tests, people were very
>> attached to the particular timing and spacing of the current output.  So
>> I'm not sure people will like this.
>
> and so is this:
>
>> The timing output is very popular.  Where is that in the TAP output?
>
> Both of those things are fairly critical for test development.  You
> need to know what else might be running in parallel with a test case,
> and you need to know whether you just bloated the runtime unreasonably.
>
> More generally, I'm unhappy about the proposal that TAP should become
> the default output.

That's not my proposal though, my proposal is that the traditional format
should be the default output (with the parallel test info added back, that was
my bad), and that TAP is used in automated test runners like in meson.  Hiding
the timing in TAP was (as mentioned upthread) since TAP test runners generally
never show that anyways, but I'll add it back since it clearly doesn't hurt to
have even there.

> There is nothing particularly human-friendly
> about it, whereas the existing format is something we have tuned to
> our liking over literally decades.  I don't mind if there's a way to
> get TAP when you're actually intending to feed it into a TAP-parsing
> tool, but I am not a TAP-parsing tool and I don't see why I should
> have to put up with it.

I totally agree, and that's why the patch has the traditional format - without
all the boilerplate - as the default.  Unless opting-in there is no change over
today, apart from the boilerplate.

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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Roberto C. Sánchez
Дата:
Сообщение: Re: Request for assistance to backport CVE-2022-1552 fixes to 9.6 and 9.4
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Re-order "disable_on_error" in tab-complete COMPLETE_WITH