Robins,
* Robins Tharakan (tharakan@gmail.com) wrote:
> On 19 February 2017 at 17:02, Robins Tharakan <tharakan@gmail.com> wrote:
> > On Sun, 19 Feb 2017 at 10:08 Stephen Frost <sfrost@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