On Wed, Oct 18, 2017 at 2:30 PM, Nico Williams <n...@cryptonector.com> wrote:
> 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. > True, though at that point the superuser who wants to cover their tracks could probably just edit your functions... > 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. > Nothing concrete... > > 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. > Ideally if implementing what you describe we'd want it accessible from any procedural language, not just pl/pgsql. Also, GET STACKED DIAGNOSTICS is documented as being exposed only within an exception handler. > > 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 I'd probably expose the stack as an array... David J.
