PostgreSQL过程语言 – PL / pgSQL和SQL之间的差异

发布时间：2020-12-13 16:22:10 所属栏目：百科来源：网络整理

导读：任何人都可以总结一下之间的区别： http://www.postgresql.org/docs/9.1/static/xfunc-sql.html 和 http://www.postgresql.org/docs/9.1/static/plpgsql.html ？要点：概念差异给家庭带来问题,方便使用政治问题 PL / PgSQL和普通SQL函数都是更大工具集的

任何人都可以总结一下之间的区别：

http://www.postgresql.org/docs/9.1/static/xfunc-sql.html

和

http://www.postgresql.org/docs/9.1/static/plpgsql.html

？

要点：

>概念差异
>给家庭带来问题,方便使用
>政治问题

PL / PgSQL和普通SQL函数都是更大工具集的一部分,应该在该上下文中查看.我倾向于用升序复杂性和成本匹配的上升功率来考虑它,你应该使用最简单的工具来完成这项工作：

>尽可能使用视图
>如果视图不合适,请使用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函数可以包含多个语句;最后一个语句是函数的结果.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!