Using stored procedures as security mechanisms

If a stored procedure and all underlying objects are owned by the same user, that owner can grant users permission to use the procedure without granting permissions on the underlying objects. For example, you might give a user permission to execute a stored procedure that updates a row-and-column subset of a specified table, even though that user does not have any other permissions on that table.

You can create a procedure using execute as owner or execute as caller, which checks runtime permissions, executes DDL, and resolves objects names on behalf of the owner or caller respectively.

Procedures defined with execute as owner, execute as caller, or with no execute as clause, can be nested inside procedures defined with execute as owner or execute as caller. Similarly procedures defined with execute as owneror execute as caller can be nested inside procedures defined without the execute as clause.

set session authorization statement is not allowed inside the procedure created with execute as owner even if the statement is in a nested procedure which is not defined as execute as owner.

See Executing a procedure with execute as owner or execute as caller. For syntax see, create procedure in Reference Manual: Commands.