Oh! Of course! The local database doesn't know anything about the role privileges on the remote database, so the information isn't even available on the local database to somehow take the union of all the privileges of foo and bar because they are defined on the remote database. Thanks for responding. I got so wrapped up in our simple use case (where any individual_user in the local_group would connect to foreign_server as the same foreign_user) and couldn't come up with a counter example.
For our use case, can you think of any other way to do it besides creating a user mapping for every member of local_group? Gilberto's suggestion of setting the session authorization (I think?) won't work because the individual_users don't have privileges to set that. ("ERROR: permission denied to set session authorization")
Thanks again for your responses; I appreciate the help!
Natalie
> On Jul 16, 2015, at 3:12 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>
> Natalie Wenz <nataliewenz@xxxxxxxxxxx> writes:
>> Would it be necessary to disambiguate?
>
> Of course. If the mapping for group_x says to connect to the remote
> server as user foo, while the mapping for group_y says to connect
> as user bar, then it matters which one we use. But there would be no
> principled way to choose, if the current userid is a member of both
> group_x and group_y.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
