FYI, Tom just applied a patch to properly detect/fix this issue.
---------------------------------------------------------------------------
On Mon, Jul 11, 2016 at 10:15:38PM -0400, David G. Johnston wrote:
> 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:
>
>
>
> Fun 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=>
>
> 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
> configuration). 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 its 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.
>
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
