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 по дате отправления: