Stephen Frost <[EMAIL PROTECTED]> writes: >> Here's a much better version of the SET ROLE work. I'm reasonably happy >> with it. The only parts I don't like are that I had to do some ugly >> things in gram.y to avoid making NONE reserved, and I can't seem to see >> how to avoid having ROLE be reserved (I understand it was reserved in >> SQL99 but not in SQL2003...).
> Updated yet again, fixing a bug in the prior one that caused it to not > work properly, and some additional things: I don't think this patch works; it certainly doesn't do what I'd expect to happen with SECURITY DEFINER functions. At the very least you'd need to make fmgr_security_definer save/restore the current role setting. But I doubt that this is even the direction we want to head in. After rereading SQL99 4.31, I don't think there is any need to distinguish CURRENT_USER from CURRENT_ROLE, mainly because our implementation does not distinguish users from roles at all. (Which I think is good.) So ISTM we should not change GetUserId() as you propose, but leave it alone and implement SetRole approximately like SetSessionUserId is implemented, ie, setting a background value that may sometimes get copied into CurrentUserId. The "stack" aspect only matters to the extent that SetRoleId has precedence over SetSessionUserId for determining the outside-a-transaction value of CurrentUserId. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match