On Wed, Oct 18, 2017 at 02:13:29PM -0700, David G. Johnston wrote: > > More useful than this, for me, would be a way to get the top-most user. > > That would be "session_user"?
It's not quite since there's a difference between SET SESSION AUTHORIZATION and SET SESSION ROLE. But yes, it's what I'm using now. > > Introducing the concept of a stack at the SQL level here seems, at > > > first glance, to be over-complicating things. > > > > Because of the current implementation of invocation of SECURITY DEFINER > > functions, a stack is trivial to build, since it's a list of nodes > > allocated on the C stack in fmgr_security_definer(). > > Not saying its difficult (or not) to code in C; but exposing that to SQL > seems like a big step. Really? Why? I mean, there's an implicit function invocation stack already. Reifying some bits of the function call stack is useful. I can't think of how this particular reification would be dangerous or set a bad precedent. Hmmm, oh, I forgot about GET DIAGNOSTICS! The stack is already exposed to SQL. Maybe we could add a CURRENT_USER item to GET STACKED DIAGNOSTICS or to the PG_CONTEXT. > If I was in position to dive deeper I wouldn't foreclose on the stack idea > but I'd be inclined to see if something else could be made to work with > reasonable effort. I would think that the more general approach, if easy enough to implement, would be better. I can (and will) live with using session_user instead of current_user, for now. But I'm willing to contribute a patch. Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
