Re: [COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed
Date
Msg-id 8985.1460050231@sss.pgh.pa.us
Whole thread Raw
Responses Re: [COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed  (Stephen Frost <sfrost@snowman.net>)
Regression test CREATE USER/ROLE usage  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> In pg_dump, include pg_catalog and extension ACLs, if changed

This patch added a regression test step that creates some roles
and doesn't drop them again.  This is unacceptable, because

(1) it breaks the ability to do "make installcheck" more than once.

(2) it leaves roles lying around in a production installation,
if installcheck is used there.

And it doesn't even adhere to the convention we've agreed to about
naming test roles regress_something.  OK, it's not as dangerously
broken that way as rowsecurity.sql, which is (still) creating roles
named "alice" and "bob", but it's not acceptable like this.

It'd be possible to fix (1) by adding "drop if exists", but I think the
whole thing is wrongheaded due to (2).  Perhaps the needs of the test
could be met by granting/revoking some rights explicitly to current_user
(ie, the test superuser)?  That wouldn't have any real effects on a
superuser, but it would provide some grist for testing the behavior.
Or you could test this behavior in some other setting than the core
regression tests; perhaps in a TAP test for pg_dump.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: In pg_dump, include pg_catalog and extension ACLs, if changed