On Thu, April 20, 2006 4:21 pm, Tom Lane wrote: > "A.M." <agentm@xxxxxxxxxxxxxxxxxxxxx> writes: > >> It seems I am stuck so please allow me to propose an extension: >> SET SESSION AUTHORIZATION user [WITH PASSWORD 'password]; >> > > This idea is extremely unlikely to be accepted, as the password would be > at risk of exposure in places like the pg_stat_activity view. > > I think the correct way to do what you want is via a SECURITY DEFINER > function. Perhaps I can't wrap my head around it- I have the SQL as a string in a table. I interpret that you propose that I accept only function names and allow users to create security definer functions which I then call as the superuser (carefully checking for the security definer flag). What about commands that can't be run from within transactions? I guess there is no way to stream arbitrary SQL in a permissions sandbox if the original login user isn't the one I want. The security definer method is a good enough workaround. Thanks. -M
