Re: Bug in pg_dump

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.

In response to

Responses

Browse pgsql-hackers by date

  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