Re: Improving test coverage of extensions with pg_dump

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving test coverage of extensions with pg_dump
Date: 2015-07-30 02:48:47
Message-ID: CAB7nPqS7gB1LEdOiHiTTBWGPWK4OuJa3UUOT8qkHwjS1McYwxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 30, 2015 at 5:54 AM, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
> What I do not like though is how the path src/test/tables_fk/t/ tells us
> nothing about what features are of PostgreSQL are tested here. For this I
> personally prefer the earlier versions where I think that was clear.

+Simple module used to check data dump ordering of pg_dump with tables
+linked with foreign keys.
The README mentions that this is to test pg_dump, perhaps referring to
the TAP tests makes sense as well?

> Another thought: would it be worthwhile to also add an assertion to check if
> the data really was restored properly or would that just be redundant code?

That seems worth doing, hence added something for it. Thanks for the suggestion.

At the same time I have added an entry in .gitignore for the generated
tmp_check/.
Regards,
--
Michael

Attachment Content-Type Size
0001-Add-TAP-test-for-pg_dump-checking-data-dump-of-exten.patch text/x-patch 5.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-07-30 02:57:13 Re: The real reason why TAP testing isn't ready for prime time
Previous Message Peter Geoghegan 2015-07-30 01:05:59 Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"