PostgreSQL过程语言-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交谈了。

当您认为需要某个功能时，通常一个视图就足够了。即使SELECT对于整个视图而言，这是极其昂贵的，但WHERE引用该视图的查询中的子句通常会下推到视图中，并可能导致非常不同的查询计划。从将SQL函数转换为视图，我经常获得很大的性能提升。

您主要发现您无法使用视图而应该考虑使用SQL函数的时间是：

• 需要不能表示为简单WHERE子句的参数，例如WITH表达式中的参数
• 您需要通过SECURITY DEFINER函数来实现安全性屏障，而security_barrierPostgreSQL 9.2及更高版本中的视图不足以满足您的需求。
• 您需要优化程序不会将其压入视图子条款中的参数，而是想要更直接地控制它。要么
• 有很多参数，或者有很多重复的参数，因此将查询编写为视图是不切实际的。

对于大多数这些任务，普通的SQL函数可以正常工作，并且通常比PL / PgSQL更易于阅读。SQL函数声明STABLE或IMMUTABLE（而不是还宣布STRICT或SECURITY DEFINER）也可以联到调用语句。这消除了函数调用的开销，并且当优化器将调用函数中的WHERE条件压入SQL函数时，有时还可以带来巨大的性能优势。只要SQL函数足以完成任务，就使用它们。

当您需要大量逻辑时，SQL函数主要不能起作用。如果/然后/其他您无法表达为CASE语句的操作，大量重复使用计算结果，从块中建立值，错误处理等。那么PL / PgSQL就派上用场了。当您无法使用SQL函数或它们不合适时，请选择PL / PgSQL，例如：

• 通过EXECUTE语句执行动态SQL和动态DDL
• 当您想对RAISE日志或客户端进行错误/警告时
• 当您需要异常处理时-您可以使用EXCEPTION块捕获和处理错误，而不是使整个事务因错误而终止
• 不适合复杂的条件逻辑CASE ... WHEN非常好
• 大量重复使用您无法适应的计算值WITH和CTE
• 建立动态记录
• 您需要在生成结果集之后执行操作

使用通用表表达式（CTE），尤其是可写CTE，WITH RECURSIVE我发现我使用PL / PgSQL的次数比以前少了很多，因为SQL更具表现力和功能。我现在更多地使用视图和普通的SQL函数。值得记住的是，普通的SQL函数可以包含多个语句。最后一条语句是函数的结果。

plpgsql是一种成熟的过程语言，带有变量，循环结构等。SQL函数只是子查询。SQL函数（无论已声明STABLE还是IMMUTABLE未声明STRICT）通常可以内联到调用查询中，就像在每个引用上写出来一样。