Sean,

> The analysis of FB privileges can be just as confusing, today, given
> that the user can choose a role themselves on sign-in.

But the user can only choose one role from the roles that were granted to
that user already, so what's the confusion? You know what you granted. If
someone logs on with an illegal role, that role is discarded. I seem to
understand that you deem inappropriate that a user can select a role at
connection time and worse even that those roles can be switched once the
attachment is done.

Maybe it would be even more controversial to discuss how the engine
calculates rights when roles can be changed dynamically. Currently, when a
request is compiled, access permissions are calculated based on the current
user and the current role (if any). Views use another model where the
current user is replaced by the owner/creator of the view. If we go to
dynamic roles or we cache statements, security checks have to move to
another place (at the beginning of execution, for example). The SQL model
says that all access paths should be checked, regardless of whether they
will be effectively executed or not. At least for me, this means that you no
longer will get a permission denied message while preparing a request.

It seems that people here aren't in mood to tolerate the idea of another
fork just for experimentation sake.
:-)

C.