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