Re: Clean up some pg_dump tests

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-10 08:03:47
Message-ID: 8b943417-3f5b-4bb5-9d49-54d7de78acc6@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Attachment Content-Type Size
v2-0001-Clean-up-some-pg_dump-tests.patch text/plain 5.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Giampaolo Capelli 2023-10-10 08:17:54 Re: [PoC] run SQL over ciphertext
Previous Message tender wang 2023-10-10 07:58:22 Re: Problem, partition pruning for prepared statement with IS NULL clause.