PostgreSQL函数可以设置被调用时的角色，以及参数。详细的语法如下：
当函数被调用时，可以选择以创建函数的角色执行函数，或者以调用者的角色执行函数（默认）。
同时，我们还可以设置函数被调用时的参数。
我们可以跟踪一下，跟踪角色需要用到session_user和current_user，这两者的差别可参考如下代码：
src/backend/utils/init/miscinit.c
session_user是指登陆数据库时的角色或者被SET SESSION AUTHORIZATION设置的角色。
current_user是指set role设置的角色，或者继承自session user，或者是函数调用时定义的角色。
举个例子，先搞明白这两个用户的含义：
创建测试函数：
这里的security definer表示调用函数时，使用函数owner的权限进行调用。
set search_path to 'public'，表示在调用函数时，使用这个值作为search_path。
使用digoal用户连接到postgres数据库，并调用postgres.f1()函数：
从NOTICE可以看到我们对函数的设置起作用了。search_path是我们设置的public，而不是默认的 "$user",public。
current_role则是函数的definer postgres。
因此我们使用security definer时，需特别注意，因为可能造成权限升级，例如本文使用超级用户创建的security definer函数。
我们把这个函数的security改为invoker。再次使用digoal调用f1()，可以看到current_role是digoal了。
下面举个例子，说明security definer的不安因素。使用超级用户创建一个函数如下，用于检查用户是否通过密码认证。
但是如果设置为security definer，想想有什么安全隐患呢？
这样看貌似没有隐患，但是因为函数中没有使用schema.table的方式，所以我们可以使用普通用户自己建立一张认证表，并自定义search_path来修改扫描优先级，来通过认证，甚至可以使用临时表的SCHEMA，都不需要修改search_path（因为临时表schema优先级被排在最前），偷偷就搞定了。
为了提高security definer函数的安全性。可以有以下方法。
1. 建议在里面使用的函数或表等一切对象，都使用schema强制指定。
2. 设置search_path, 防止普通用户钻空子。
例如：
现在钻不了空子了：
或者在调用函数时使用设置的search_path，将普通用户能创建表的schema都去除。
现在也安全了：
不过这里还是推荐在函数中使用schema，防止这类问题。
文章来源:本文来自云栖社区合作伙伴"DBAplus"
