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

From Andres Freund
Subject Re: Improving test coverage of extensions with pg_dump
Date
Msg-id 20150902173558.GK5286@alap3.anarazel.de
Whole thread Raw
In response to Re: Improving test coverage of extensions with pg_dump  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Improving test coverage of extensions with pg_dump  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 2015-09-02 14:30:33 -0300, Alvaro Herrera wrote:
> I was thinking in having this be renamed src/test/modules/extensions/
> and then the extension contained here would be renamed ext001_fk_tables
> or something like that; later we could ext002_something for testing some
> other angle of extensions, not necessarily pg_dump related.

The largest dataset we have for this is the current regression test
database, it seems a waste not to include it...

> That's another option, but we've had this idea for many years now and it
> hasn't materialized.

But that's just minimally more complex than what's currently done in
that test and in the pg_upgrade test?

> As I recall, Andrew Dunstan has a module that
> tests cross-version pg_upgrade and one thing he does is dump both and
> compare; the problem is that there are differences, so he keeps a count
> of how many lines he expect to differ between any two releases.

I'm not suggesting to do anything cross-release - that'd indeed be
another ballpark.

Just that instead of a pg_dump test that tests some individual things we
have one that tests the whole regression test output and then does a
diff?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Improving test coverage of extensions with pg_dump
Next
From: Alvaro Herrera
Date:
Subject: Re: Improving test coverage of extensions with pg_dump