Re: Allow pg_dumpall to work without pg_authid

On Sun, Feb 26, 2017 at 3:43 PM, Robins Tharakan <tharakan(at)gmail(dot)com> 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 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
should also patch the tools, though maybe a better idea would be to
restrict the superuser a bit less.

My basic concern here is that I don't want half of our tools to end up
with special-purpose flags that serve only to unbreak Amazon RDS.
That can't be a good solution to anything. It will lead to extra work
for us and confusion for users about whether they should be using
them. People are going to see this --avoid-pgauthid and wonder why
it's there. And the next time Amazon RDS breaks something, we'll get
a different flag someplace else to fix that problem. If we call them
all --unbreak-amazon-rds instead of things like --avoid-pgauthid, then
it will be clear when they need to be used, but why would we accept
the job of working around the defects in Amazon's fork of PG? I'm
already responsible for helping maintain one fork of PostgreSQL, but
I'm not under any illusion that I get to do that by putting changes
that make that easier into the community code base. Plus, for that
work, I get paid.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company