Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 3/21/17 23:34, Tom Lane wrote: > Peter Eisentraut writes: >> No answer. Can we remove this chunk? > >>> + if (no_role_passwords && binary_upgrade) > > Perhaps, but why? ISTM that trying to run pg_upgrade as non-superuser > is a nonstarter for a number of

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 15 March 2017 at 21:56, Stephen Frost wrote: > Greetings, > > * Sachin Kotwal (kotsac...@gmail.com) wrote: >> Thanks. I understand this is small but new feature and not bug fix. >> But we should be able to backpatch if there is no dependency. > > No, it's a new feature and

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Peter Eisentraut writes: > No answer. Can we remove this chunk? >> +if (no_role_passwords && binary_upgrade) Perhaps, but why? ISTM that trying to run pg_upgrade as non-superuser is a nonstarter for a number of reasons, while if you're superuser you do

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 3/13/17 16:41, Peter Eisentraut wrote: > Why this? No answer. Can we remove this chunk? > + if (no_role_passwords && binary_upgrade) > + { > + fprintf(stderr, _("%s: options --no-role-passwords and > --binary-upgrade cannot be used together\n"), > +

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Greetings, * Sachin Kotwal (kotsac...@gmail.com) wrote: > Thanks. I understand this is small but new feature and not bug fix. > But we should be able to backpatch if there is no dependency. No, it's a new feature and won't be back-patched. > It will help users to get benefit of this feature for

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Hi Stephen, Thanks. I understand this is small but new feature and not bug fix. But we should be able to backpatch if there is no dependency. It will help users to get benefit of this feature for g96 and pg95 in RDS until they will have pg10 in RDS. If It is against community policy then it is

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Greetings, * Sachin Kotwal (kotsac...@gmail.com) wrote: > Can we have backpatch this patch to PostgreSQL 9.6 and earlier releases ? No. This is a new feature and new features are not back-patched. Thanks! Stephen signature.asc Description: Digital signature

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Thanks for nice patch related to AWS RDS. Can we have backpatch this patch to PostgreSQL 9.6 and earlier releases ? Regards, Sachin On Sun, Mar 5, 2017 at 12:30 PM, Simon Riggs wrote: > On 28 February 2017 at 17:49, Simon Riggs wrote: > > >

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Why this? + if (no_role_passwords && binary_upgrade) + { + fprintf(stderr, _("%s: options --no-role-passwords and --binary-upgrade cannot be used together\n"), + progname); + fprintf(stderr, _("Try \"%s --help\" for more

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 5 March 2017 at 18:00, Simon Riggs wrote: > I'm looking to commit the patch version I posted, so I would like your > comments that it does continue to solve the problems you raised. > ​Thanks Simon, for confirming. Yes, the updated patch does solve the problem.​ -

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 28 February 2017 at 17:49, Simon Riggs wrote: > I've edited the stated reason for the patch on the CF app, so its > clearer as to why this might be acceptable. Robins, I'm looking to commit the patch version I posted, so I would like your comments that it does

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 28 February 2017 at 16:12, Stephen Frost wrote: > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: >> On Sun, Feb 19, 2017 at 12:24 AM, Robins Tharakan wrote: >> > I would like to work on a patch to accommodate restricted environments >> >

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Sun, Feb 19, 2017 at 12:24 AM, Robins Tharakan wrote: > > I would like to work on a patch to accommodate restricted environments (such > > as AWS RDS Postgres) which don't allow pg_authid access since their > >

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 26 February 2017 at 21:37, Robert Haas wrote: > > How's that not a bug? I mean, it's reasonable for someone to want to > restrict the superuser in a cloud environment, but if they restrict it > so much that you can't take a backup with standard tools, I'd say they >

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On Sun, Feb 26, 2017 at 3:43 PM, Robins Tharakan wrote: > To confirm, this did originate by trying to accommodate a fork. But what > I can say is that this doesn't appear to be a bug; what they call > Super-User isn't effectively one. How's that not a bug? I mean, it's

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 26 February 2017 at 19:26, Robert Haas wrote: ​​ > I am a little surprised that this patch has gotten such a good > reception. We haven't in the past been all that willing to accept > core changes for the benefit of forks of PostgreSQL; extensions, sure, > but forks?

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On Sun, Feb 19, 2017 at 12:24 AM, Robins Tharakan wrote: > I would like to work on a patch to accommodate restricted environments (such > as AWS RDS Postgres) which don't allow pg_authid access since their > definition of Superuser is just a regular user with extra

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 22 February 2017 at 07:33, Robins Tharakan wrote: > Stephen, > > On 20 February 2017 at 08:50, Stephen Frost 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

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On Wed, Feb 22, 2017 at 06:33:10PM +1100, Robins Tharakan wrote: > Stephen, > > On 20 February 2017 at 08:50, Stephen Frost 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

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Stephen, On 20 February 2017 at 08:50, Stephen Frost 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

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Robins, * Robins Tharakan (thara...@gmail.com) wrote: > On 19 February 2017 at 17:02, Robins Tharakan wrote: > > On Sun, 19 Feb 2017 at 10:08 Stephen Frost wrote: > >> If anything, it should use pg_roles, not pg_user. > >> > >> I don't really like the

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On 19 February 2017 at 17:02, Robins Tharakan wrote: > > On Sun, 19 Feb 2017 at 10:08 Stephen Frost wrote: > >> If anything, it should use pg_roles, not pg_user. >> >> I don't really like the "--avoid-pgauthid" option, but "--no-passwords" >> would

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On Sun, 19 Feb 2017 at 10:08 Stephen Frost 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. > > Am sorry, I meant pg_roles (FWIW, the github URL given earlier uses

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Greetings, * Robins Tharakan (thara...@gmail.com) wrote: > I would like to work on a patch to accommodate restricted environments > (such as AWS RDS Postgres) which don't allow pg_authid access since their > definition of Superuser is just a regular user with extra permissions. > > Would you

[HACKERS] Allow pg_dumpall to work without pg_authid

Hi, I would like to work on a patch to accommodate restricted environments (such as AWS RDS Postgres) which don't allow pg_authid access since their definition of Superuser is just a regular user with extra permissions. Would you consider a patch to add a flag to work around this restriction,