Stephen, On 20 February 2017 at 08:50, Stephen Frost <sfr...@snowman.net> wrote:
> The other changes to use pg_roles instead of pg_authid when rolpassword > isn't being used look like they should just be changed to use pg_roles > instead of using one or the other. That should be an independent patch > from the one which adds the option we are discussing. > Sure. Attached are 2 patches, of which 1 patch just replaces pg_authid with pg_roles in pg_dumpall. The only exceptions there are buildShSecLabels() & pg_catalog.binary_upgrade_set_next_pg_authid_oid() which I thought should still use pg_authid. Perhaps --no-role-passwords instead? > > Makes Sense. The updated patch uses this name. > > pg_dumpall --no-pgauthid --globals-only > a.sql > > Does that then work with a non-superuser account on a regular PG > instance also? If not, I'd like to suggest that we consider follow-on > patches to provide options for whatever else currently requires > superuser on a regular install. > > If I understand that correctly, the answer is Yes. I didn't test all db objects, but trying to do a pg_dumpall using a non-priviledge user does successfully complete with all existing users dumped successfully. pg_dumpall --globals-only --no-role-password > a.sql > Yes, please do create a commitfest entry for this. > > Created Commitfest entry. - robins
use_pgroles_instead_of_pg_authid.diff.gz
Description: GNU Zip compressed data
no_role_password.diff.gz
Description: GNU Zip compressed data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
