On Thu, Oct 26, 2017 at 09:21:24AM +0200, Pavel Stehule wrote: > Comments, notes?
I like it.
I would further like to move all of postgresql.conf into the database, as much as possible, as well as pg_ident.conf and pg_hba.conf.
Variables like current_user have a sort of nesting context functionality: calling a SECURITY DEFINER function "pushes" a new value onto current_user, then when the function returns the new value of current_user is "popped" and the previous value restored.
My proposal doesn't expecting with nesting, because there is only one scope - schema / session - but I don't think so it is necessary
current_user is a function - it is based on parser magic in Postgres. The origin from Oracle uses the feature of ADA language. When function has no parameters then parenthesis are optional. So current_user, current_time are functions current_user(), current_time().
It might be nice to be able to generalize this.
Questions that then arise:
- can one see up the stack? - are there permissions issues with seeing up the stack?
these variables are pined to schema - so there is not any relation to stack. It is like global variables.
Theoretically we can introduce "functional" variables, where the value is based on immediate evaluation of expression. It can be very similar to current current_user.
I recently posted proposing a feature such that SECURITY DEFINER functions could observe the _caller_'s current_user.
your use case is good example - this proposed feature doesn't depend on stack, depends on security context (security context stack) what is super set of call stack