PostgreSQL中的IF函数和MySQL一样

Question

我试图将IF函数从MySQL 复制到PostgreSQL中.

IF函数的语法是IF(condition, return_if_true, return_if_false)

我创建了以下公式:

CREATE OR REPLACE FUNCTION if(boolean, anyelement, anyelement)
   RETURNS anyelement AS $$
BEGIN
    CASE WHEN ($1) THEN
    RETURN ($2);
    ELSE
    RETURN ($3);
    END CASE;
    EXCEPTION WHEN division_by_zero THEN
    RETURN ($3);
END;
$$ LANGUAGE plpgsql;

它适用于大多数事情,if(2>1, 2, 1)但它会引发错误:

if( 5/0 > 0, 5, 0)

致命错误除以零.

在我的程序中,我无法检查分母,因为条件是由用户提供的.

有什么办法吗？也许如果我们可以将第一个参数从布尔值替换为其他东西,因为在这种情况下函数将起作用,因为它将引发并返回异常.

Answer 1

使用布尔参数,除非在函数被调用之前,除以零将始终抛出异常(这是一件好事).有没有什么可以做的.它已经发生了.

CREATE OR REPLACE FUNCTION if(boolean, anyelement, anyelement)
 RETURNS anyelement LANGUAGE SQL AS
$func$
SELECT CASE WHEN $1 THEN $2 ELSE $3 END
$func$;

我强烈建议不要使用一个名为的函数if.IF是PL/pgSQL中的关键字.如果使用用PL/pgSQL编写的用户定义函数,这将非常混乱.

只需CASE直接使用标准SQL表达式即可.

另一种方法是采用text参数并使用动态SQL对其进行评估.

概念证明

你要求的是这样的:

CREATE OR REPLACE FUNCTION f_if(_expr text
                              , _true anyelement
                              , _else anyelement
                              , OUT result anyelement)
  RETURNS anyelement LANGUAGE plpgsql AS
$func$
BEGIN
   EXECUTE '
   SELECT CASE WHEN (' || _expr || ') THEN $1 ELSE $2 END' -- !! dangerous !!
   USING _true, _else
   INTO result;

   EXCEPTION WHEN division_by_zero THEN
   result := _else;
   -- possibly catch more types of exceptions ...
END
$func$;

测试:

SELECT f_if('TRUE'   , 1, 2)  --> 1
      ,f_if('FALSE'  , 1, 2)  --> 2
      ,f_if('NULL'   , 1, 2)  --> 2
      ,f_if('1/0 > 0', 1, 2); --> 2

这对于不受信任的用户来说是一个很大的安全隐患.阅读@ Craig关于使其更加安全的答案.但是,我没有看到它是如何制成防弹的,永远不会使用它.

Answer 2

PostgreSQL遵循标准

此行为似乎由SQL标准指定.这是我第一次看到一个真正问题的案例; 您通常只使用CASE表达式或PL/PgSQL BEGIN ... EXCEPTION块来处理它.

MySQL的默认行为是危险和错误的.它只能以这种方式支持依赖于此行为的旧代码.当严格模式处于活动状态时(它绝对应该是),它已在较新版本中修复,但遗憾的是尚未成为默认模式.使用MySQL时,始终启用或.STRICT_TRANS_TABLESSTRICT_ALL_TABLES

ANSI标准的零分割有时会很痛苦,但它也可以防止导致数据丢失的错误.

SQL注入警告,考虑重新设计

如果您正在从用户执行表达式,那么很可能会出现SQL注入问题.根据您的安全要求,您可以使用它,但如果您不完全信任所有用户,那将非常糟糕.请记住,您的用户可能会被欺骗从其他地方输入恶意代码.

考虑重新设计以向用户公开表达式构建器,并使用查询构建器从用户表达式创建SQL.这将更复杂,但更安全.

如果您不能这样做,请查看是否可以解析用户输入的表达式为抽象语法,在执行前验证它,然后根据解析的表达式生成新的SQL表达式.这样你至少可以限制他们可以写的东西,所以他们不会把任何恶意搞砸到表达中.您还可以重写表达式以添加检查零分割等内容.为代数表达式查找(或编写)解析器可能不是很难,但它取决于您需要让用户编写什么类型的表达式.

至少,应用程序需要使用仅具有SELECT表权限的角色("用户"),不是超级用户,并且不拥有表.这将最小化任何SQL注入将导致的伤害.

CASE不会像写的那样解决这个问题

在任何情况下,由于您当前未验证并且无法检查用户的表达式,因此无法使用SQL标准CASE语句来解决此问题.因为if( a/b > 0, a, b)你通常会写下这样的东西:

CASE
    WHEN b = 0 THEN b
    ELSE CASE 
        WHEN a/b=0 THEN a
        ELSE b
    END
END

这显式处理了零分母的情况,但只有在你可以打破表达式时才有可能.

丑陋的解决方法#1

另一种解决方案是让Pg返回一个占位符,而不是通过定义替换除法运算符或函数来引发除零除外.这只能解决除零情况,而不是其他情况.

我想回归,'NaN'因为这是合乎逻辑的结果.不幸的是,'NaN'大于不小于的数字,并且你想要一个小于或类似假的结果.

regress=# SELECT NUMERIC 'NaN' > 0;
 ?column? 
----------
 t
(1 row)

这意味着我们必须使用返回NULL的icky hack:

CREATE OR REPLACE FUNCTION div_null_on_zero(numeric,numeric) returns numeric AS $$
VALUES (CASE WHEN $2 = 0 THEN NULL ELSE $1/$2 END)
$$ LANGUAGE 'SQL' IMMUTABLE;

CREATE OPERATOR @/@ (
    PROCEDURE = div_null_on_zero(numeric,numeric),
    LEFTARG = numeric,
    RIGHTARG = numeric
);

用法:

regress=# SELECT 5 @/@ 0, 5 @/@ 0>0, CASE WHEN 5 @/@ 0 > 0 THEN 5 ELSE 0 END;
 ?column? | ?column? | case 
----------+----------+------
          |          |    0
(1 row)

您的应用程序可以将传入表达式中的"/"重写@/@为您选择的任何运算符名称.

这种方法存在一个相当严重的问题,那就是@/@具有不同的优先级,/因此没有明确括号的表达式可能无法按预期进行评估.您可以通过创建新模式来解决这个问题,定义/在该模式中命名的运算符,该运算符执行null-on-error技巧,然后search_path在执行用户表达式之前将该模式添加到您的模式中.不过,这可能是一个坏主意.

丑陋的解决方法#2

由于你无法检查分母,我所能想到的就是将整个事物包装在一个DO块(Pg 9.0+)或PL/PgSQL函数中,并从表达式的评估中捕获任何异常.

Erwin的答案提供了一个比我更好的例子,所以我删除了这个.无论如何,这是一件非常危险的事情,不要这样做.您的应用需要修复.