Hi Stephen,
On Tue, Sep 04, 2018 at 04:14:15PM -0700, Michael Paquier wrote:
> On Tue, Sep 04, 2018 at 06:02:51PM -0400, Stephen Frost wrote:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>> I'm confused. Isn't the point of that script exactly to create a modified
>>> extension for testing pg_dump with?
>
> Not really, the regression tests run for pg_regress and the TAP test
> suite are two completely isolated things and share no dependencies.
> e54f757 has actually changed test_pg_dump.sql so as it adds regression
> tests for pg_init_privs for ALTER EXTENSION ADD/DROP, and visibly those
> have been added to test_pg_dump because they were easier to add there,
> and this has no interactions with pg_dump. What I think should have
> been done initially is to add those new tests in test_extensions
> instead.
I am able to come back to this thread, and I still don't grep from where
sql/test_pg_dump.sql is called. Stephen, if the test suite is aiming at
tracking that pg_init_privs is correctly set up with ALTER EXTENSION
ADD/DROP, shouldn't it also query the catalog to make sure that the
correct entries are added and removed after running the so-said command?
At least that's one way I could see to perform the necessary sanity
checks without running directly pg_dump. Perhaps I am missing
something?
>>> What I'd do is leave the final state as-is and add a "drop role if exists"
>>> at the start, similar to what some of the core regression tests do.
>>
>> I've not followed this thread but based on Tom's response, I agree with
>> his suggestion of what to do here.
>
> Not as far as I can see.. Please note that using installcheck on the
> main regression test suite does not leave around any extra roles. I can
> understand the role of having a DROP ROLE IF EXISTS though: if you get a
> crash while testing, then the beginning of the tests are repeatable, so
> independently of the root issue Tom's suggestion makes sense to me.
Attached is a patch with more comments about the intents of the test
suite, and the separate issue pointed out by Tom fixed. It seems to me
that actually checking the contents of pg_init_privs would improve the
reason why the test exists.. I would welcome input about this last
point.
--
Michael
