Re: Clean up some pg_dump tests

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Clean up some pg_dump tests
Дата
Msg-id e9d0342f-1a5a-4b49-bf41-e28d15cf92f5@eisentraut.org
обсуждение исходный текст
Ответ на Re: Clean up some pg_dump tests  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
On 10.10.23 10:03, Peter Eisentraut wrote:
> On 09.10.23 11:20, Alvaro Herrera wrote:
>> I tried this out.  I agree it's a good change.  BTW, this made me
>> realize that "unlike" is not a good name: maybe it should be called
>> "except".
> 
> right
> 
>> I would add quotes to the words "like" and "unlike" there.  Otherwise,
>> these sentences are hard to parse.  Also, some commentary on what this
>> is about seems warranted: maybe "Check that this test properly defines
>> which dumps the output should match on." or similar.
> 
> Done.
> 
> I also moved the code a bit earlier, before the checks for supported 
> compression libraries etc., so it runs even if those cause a skip.
> 
>> I didn't like using diag(), because automated runs will not alert to any
>> problems.  Now maybe that's not critical, but I fear that people would
>> not notice problems if they are just noise in the output.  Let's make
>> them test errors.  fail() seems good enough: with the lines I quote
>> above and omitting the test corrections, I get this, which seems good
>> enough:
> 
> After researching this a bit more, I think "die" is the convention for 
> problems in the test definitions themselves.  (Otherwise, you're writing 
> a test about the tests, which would be a bit weird.)  The result is 
> approximately the same.

committed



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

Предыдущее
От: torikoshia
Дата:
Сообщение: Re: RFC: Logging plan of the running query
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Test 026_overwrite_contrecord fails on very slow machines (under Valgrind)