On Thu, Oct 5, 2017 at 1:16 PM, Nico Williams <n...@cryptonector.com> wrote: >> That's an interesting point. I think that you can imagine use cases >> for either method. Obviously, if what you want to do is drill a hole >> through the Internet to another server and then expose it to some of >> your fellow users, having the FDW run with the owner's permissions >> (and credentials) is exactly right. But there's another use case too, >> which is where you have something that looks like a multi-user >> sharding cluster. You want each person's own credentials to carry >> over to everything they do remotely. > > Hmmm, I don't think that's really right. > > What I'd like instead is for the FDW client to tell the FDW server the > session_user/current_user on behalf of which it's acting, and let the > FDW server decide how to proceed. This could be done by doing a SET > SESSION fdw.client.session_user... and so on.
Isn't that the same thing as the second use case I mentioned? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
