Re: Re-enabling SET ROLE in security definer functions

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Really? What can it contain, and how are you enforcing that?

Anything except a function call. We look for non-keyword identifier followed by open parenthesis, which is probably excessively restrictive. I'd rather have something less kludgey, of course. This will also become a real nightmare if new identifier quoting approaches are introduced.

> Even more
> to the point, if you have managed to restrict it to the point where
> there's no possibility of someone executing a SET ROLE, why do you need
> any permissions switch at all?

We don't want to have to check access privileges on every object referenced by the statement, which (as I'm sure you're aware) can get real nasty real quick.

> That's isomorphic to claiming that it
> won't execute any SQL command at all, in which case you needn't worry about
> changing permissions.

Not sure what you mean here, can you elaborate?

--Ian