On Thu, Oct 12, 2017 at 9:21 PM, Stephen Frost <sfr...@snowman.net> wrote: > Yes, that means that sometimes when superusers run things they get > permission denied errors. That's always been the case, and is correct.
OK, let me try to summarize where we are with this. Currently, postgres_fdw requires a password unless you are logged in as a superuser. Jeff proposes to change that so that it requires a password if you are EITHER logged in as a superuser OR using a superuser's credentials - e.g. by selecting from a view created by a superuser. Stephen and I propose that it should be one thing or the other, and therefore that we should CHANGE the behavior to depend on whose credentials you are using, not make it an either-or thing. So when selecting from a view, whether or not you need a password would depend entirely on who owns the view, not who you are. So that gives us three options all of which are easy to implement: (1) leave it alone [favored by nobody], (2) allow based on view owner OR current user [favored by Jeff], (3) allowed based on view owner only [favored by Stephen and me]. Taken in complete isolation, this would, maybe, constitute a marginal consensus for option (2). However, Simon weighed in proposing a much broader rethink in how foreign tables work -- letting them run with either the owner's privileges or the accessor's privileges, rather than always using the accessor's privileges as they do today. Nico Williams, along with Jeff and I and others, had a lengthy discussion of the desirability of some kind of authentication-forwarding mechanisms. I view all of these questions as somewhat irrelevant to the immediate decision insofar as we could do that stuff later, or not, but they matter to the extent that they constitute tacit votes on what to do about the patch on hand. Unless we can get a clearer consensus here, I think we should just mark this patch as Rejected. I hate to do nothing here, but neither doing something with which I disagree nor trying to unilaterally impose my own opinion seem better. Last call for other votes (or changes of opinion). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
