On Thu, Oct 5, 2017 at 1:16 PM, Nico Williams <nico@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
