From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in pg_dump |
Date: | 2015-03-03 21:48:47 |
Message-ID: | 54F62C3F.8070702@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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-out extension 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-03-03 21:59:23 | Re: Add more tests on event triggers |
Previous Message | Robert Haas | 2015-03-03 21:43:01 | Re: NULL-pointer check and incorrect comment for pstate in addRangeTableEntry |