Good. For these three it may be good to call out that the fact that the
privileges include the right to set the current role to a role for
which the definer has privileges. A priori, no role is set, i.e. even
if the invoker has set a current role, the routine running with
definer's rights has no current role set initially.
The internals for AliasInfo is not public/exposed, so I suggest just
leave this section unchanged (implementation detail).
> If used within a function or procedure created with definer's rights,
> USER and CURRENT_USER return the authorization identifier of the
> definer, whereas SESSION_USER returns the authorization identifier of
> the "first" caller, that is, the user of the top level
> session. [Question: does this mean the invoker?]
Yes, it's better to use "invoker" I guess. Also the quotes around first look bad.
Maybe we can reword to something like:
"When used outside stored routines, USER alias CURRENT_USER and
SESSION_USER return the same value, i.e. the user identifier of
the user which created the SQL session.
SESSION_USER also always returns this value when used inside stored routines.
USER/CURRENT_USER, however, when used within a routine defined with
EXTERNAL SECURITY DEFINER, will return the user identifier of the user
that owns the schema of the routine. This is usually the creating user
although the database owner could be the creator as well."
This verbiage was just a general comment on the fact that we can't track such dependencies.
Actually, it applies for invoker's rights routines as well. I suggest that we just remove this altogether.