14

我正在尝试将该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)

致命错误除以零。

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

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

4

2 回答 2

11

PostgreSQL 遵循标准

这种行为似乎是由 SQL 标准指定的。不过，这是我第一次看到这是一个真正的问题的案例。您通常只使用CASE表达式或 PL/PgSQLBEGIN ... 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 的回答提供了一个比我更好的例子，所以我删除了这个。无论如何，这是一件可怕而危险的事情，不要这样做。您的应用程序需要修复。

于 2012-09-13T22:06:54.223 回答
9

使用布尔参数，除以零总是会抛出异常（这是一件好事），甚至在你的函数被调用之前。您对此无能为力。它已经发生了。

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 编写的用户定义函数，这将非常混乱。

直接使用标准 SQL 表达式CASE即可。

另一种方法是接受一个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 的回答，了解如何使其更安全。但是，我看不到它是如何做到防弹的，并且永远不会使用它。

于 2012-09-13T21:19:40.013 回答