From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clean up some pg_dump tests |
Date: | 2023-10-18 06:16:47 |
Message-ID: | e9d0342f-1a5a-4b49-bf41-e28d15cf92f5@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-10-18 06:26:40 | Re: Test 026_overwrite_contrecord fails on very slow machines (under Valgrind) |
Previous Message | torikoshia | 2023-10-18 06:09:38 | Re: RFC: Logging plan of the running query |