http://www.postgresql.org/docs/9.1/static/xfunc-sql.html
和
http://www.postgresql.org/docs/9.1/static/plpgsql.html
？
要点：
>概念差异
>给家庭带来问题,方便使用
>政治问题
>尽可能使用视图
>如果视图不合适,请使用sql函数
>如果sql函数不合适,请使用PL / Pgsql.
>如果PL / Pgsql太有限或不够表达,请使用PL / Perl,PL / Python,PL / V8,PL / Java,或者您喜欢的任何内容
> ……如果没有PL可以完成这项工作,请使用外部程序并可能LISTEN和NOTIFY与之交谈.
当您认为需要某个功能时,很多时候视图就足够了.即使选择整个视图的代价非常昂贵,引用视图的查询中的WHERE子句通常会被下推到视图中,并可能导致非常不同的查询计划.通过将sql函数转换为视图,我经常获得很大的性能提升.
您发现的主要时间不能使用视图,并且应该考虑sql函数的时间：
>不能表示为简单WHERE子句的参数,如WITH表达式中的参数
>您希望通过Security DEFINER功能获得安全屏障,Postgresql 9.2及更高版本中的security_barrier视图不足以满足您的需求;
>您需要的参数不会被优化器推入视图的子子句中,而是希望更直接地控制它;要么
>有很多参数或者有很多重复的参数,所以将查询作为视图编写是不切实际的.
对于大多数这些任务,普通的sql函数工作正常,并且通常比PL / Pgsql更容易阅读.声明为STABLE或IMMUTABLE(也未声明为STRICT或Security DEFINER)的sql函数也可以内联到调用语句中.这消除了函数调用开销,并且当调优函数中的WHERE条件被优化器推送到sql函数时,有时也会带来巨大的性能优势.只要它们足以完成任务,就使用sql函数.
sql函数不能完成工作的主要时间是需要大量逻辑时.如果/ then / else操作不能表示为CASE语句,大量重复使用计算结果,从块中构建值,错误处理等等.PL / Pgsql就派上用场了.当你不能使用sql函数或者它们不合适时选择PL / Pgsql,例如：
>通过EXECUTE语句的动态sql和动态DDL
>当您想要升级日志或客户端的错误/警告时
>当您需要异常处理时 – 您可以使用EXCEPTION块捕获和处理错误,而不是让整个事务在出错时终止
>复杂的条件逻辑不适合CASE ……非常好
>大量重复使用您无法适应WITH和CTE的计算值
>构建动态记录
>您需要在生成结果集后执行操作
使用公用表表达式(CTE),尤其是可写CTE和WITH RECURSIVE,我发现我使用PL / Pgsql的次数比以前少得多,因为sql更具表现力和强大功能.我现在更多地使用视图和纯sql函数.值得记住的是,纯sql函数可以包含多个语句;最后一个语句是函数的结果.
原文地址：https://www.jb51.cc/postgresql/192349.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
