Re: Improving test coverage of extensions with pg_dump - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Improving test coverage of extensions with pg_dump
Date
Msg-id CAB7nPqSQr1UjZ1h8=be1wBq3mMdmM38nrjBKvBJuM--tTTY=EA@mail.gmail.com
Whole thread Raw
In response to Improving test coverage of extensions with pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Improving test coverage of extensions with pg_dump
List pgsql-hackers
On Tue, Mar 3, 2015 at 2:40 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Those patches are really simple, but then perhaps there are better or
> simpler ways than what is attached, so feel free to comment if you
> have any ideas.

Attached are new patches somewhat based on the comments provided by
Peter Eisentraut
(http://www.postgresql.org/message-id/54F62C3F.8070702@gmx.net).
- 0001 makes prove_check install the contents of the path located at
$(CURDIR)/t/extra if present, which would be the path that test
developers could use to store extensions, plugins or modules that
would then be usable by a given set of TAP tests as they are installed
in the temporary installation before launching the tests.
- 0002 is the test for pg_dump checking extensions containing FK
tables, this time integrated as a TAP test in src/bin/pg_dump, with
the extension in src/bin/pg_dump/t/extra.
IMO, this approach is scalable enough thinking long-term. And I think
that the location of those extra extensions is fine in t/ as an
hardcoded subfolder (any fresh idea being of course welcome) as this
makes the stuff in extra/ dedicated to only on set of TAP tests, and
it is even possible to set multiple extensions/modules.
Regards,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: improve pgbench syntax error messages
Next
From: Peter Eisentraut
Date:
Subject: Re: CATUPDATE confusion?