Robins, * Robins Tharakan (thara...@gmail.com) wrote: > On 19 February 2017 at 17:02, Robins Tharakan <thara...@gmail.com> wrote: > > On Sun, 19 Feb 2017 at 10:08 Stephen Frost <sfr...@snowman.net> wrote: > >> If anything, it should use pg_roles, not pg_user. > >> > >> I don't really like the "--avoid-pgauthid" option, but "--no-passwords" > >> would probably work. > >> > > '--no-passwords' is a good alternative. > > Would submit a patch soon. > > > After reviewing further, it seems that merely adding a password related > workaround wouldn't suffice. Further --no-password is already an alias for > -w, so that flag is effectively taken.
Ah, yes, that makes --no-passwords a bad name. 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. > Since the main restriction with AWS RDS is the unavailability of pg_authid, > probably that is a better basis to name the flag on. I don't like the idea of having the catalog name drive the option name. For one thing, there's been some discussion of using column-level privs on catalogs, which would actually make it such that pg_authid could be queried by regular users for the public columns. Perhaps --no-role-passwords instead? > Attaching a patch to add a new flag (--no-pgauthid) to pg_dumpall that can > dump Globals without needing pg_authid. So the following works with AWS RDS > Postgres databases. > > 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. > I'll create a Commitfest entry, if there aren't many objections. Yes, please do create a commitfest entry for this. Thanks! Stephen
Description: Digital signature