On Sun, Feb 26, 2017 at 3:43 PM, Robins Tharakan <thara...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers