Re: Bug in pg_dump - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Bug in pg_dump
Date
Msg-id 54F62C3F.8070702@gmx.net
Whole thread Raw
In response to Re: Bug in pg_dump  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Bug in pg_dump
List pgsql-hackers
On 3/1/15 2:17 PM, Stephen Frost wrote:
> Peter, if you have a minute, could you take a look at this thread and
> discussion of having TAP tests under src/test/modules which need to
> install an extension?  I think it's something we certainly want to
> support but I'm not sure it's a good idea to just run install in every
> directory that has a prove_check.

I don't think the way the tests are set up is scalable.  Over time, we
will surely want to test more and different extension dumping scenarios.We don't want to have to create a new fully
built-outextension for
 
each of those test cases, and we're going to run out of useful names for
the extensions, too.

Moreover, I would like to have tests of pg_dump in src/bin/pg_dump/, not
in remote areas of the code.

Here's what I would do:

- set up basic scaffolding for TAP tests in src/bin/pg_dump

- write a Perl function that can create an extension on the fly, given
name, C code, SQL code

- add to the proposed t/001_dump_test.pl code to write the extension

- add that test to the pg_dump test suite

Eventually, the dump-and-restore routine could also be refactored, but
as long as we only have one test case, that can wait.




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: NULL-pointer check and incorrect comment for pstate in addRangeTableEntry
Next
From: Robert Haas
Date:
Subject: Re: Add more tests on event triggers