Sorry...I keep trying to dig deeper and keep discovering/realizing stuff.
On Mon, Jul 11, 2016 at 10:08 PM, David G. Johnston <
david.g.johnston@gmail.com> wrote:
> =E2=80=8B
>>
> =E2=80=8BFun times...
> [up-thread commands still in effect]
> ALTER DATABASE postgres SET ROLE loginrole2;
> psql -U loginrole postgres
> WARNING: permission denied to set role "grouprole"
> WARNING: permission denied to set role "loginrole2"
> postgres=3D>
>
> In light of the above double-warning I'm concerned that "precedence" isn'=
t
> happening correctly here - but that could be an implementation artifact
> (the more specific combination is executed second so that it ends up
> overriding any settings attempted to be set by the less specific
> =E2=80=8Bconfiguration). In this case, though, the failed attempt to set=
the
> db+role setting would have resulted in the role setting taking effect if =
it
> was valid. I don't recall us making this distinction clear in the
> documentation.
>
>
Actually, apparently the system realizes =E2=80=8Bits attempt to SET ROLE <=
role-set
value> failed and proceeded to attempt to "SET ROLE <db-set value>" -
assuming the visible order is reflective of reality. So it does have the
necessary smarts and also fall-back-try-again logic.
The rest of the documentation observations stand.
David J.