postgresql - Postgres 13.3 中重载函数的奇怪行为

Question

我在 PG 13.3 中添加了一对重载函数来处理安全视觉，可以选择进行舍入。我通过例程运行了一些简单的示例案例，在一种情况下，输出会意外变化。我希望有人能够阐明可能导致这种不一致的原因。首先，这里是 div_safe (anycompany,anycompany):real 和 div_safe (anycompany,anycompany,integer):real 函数的代码。 (我尝试在第三个参数中将 integer 替换为 anycompany，但没有什么区别。)

------------------------------
-- No rounding
------------------------------
CREATE OR REPLACE FUNCTION tools.div_safe(
    numerator   anycompatible,
    denominator anycompatible)

RETURNS real

AS $BODY$

SELECT numerator/NULLIF(denominator,0)::real

$BODY$
  LANGUAGE SQL;

COMMENT ON FUNCTION tools.div_safe (anycompatible, anycompatible) IS
'Pass in any two values that are, or can be coerced into, numbers, and get a safe division real result.';

------------------------------
-- Rounding
------------------------------
CREATE OR REPLACE FUNCTION tools.div_safe(
    numerator    anycompatible,
    denominator  anycompatible,
    rounding_in  integer)

RETURNS real

AS $BODY$

SELECT ROUND(numerator/NULLIF(denominator,0)::numeric, rounding_in)::real

$BODY$
  LANGUAGE sql;

COMMENT ON FUNCTION tools.div_safe (anycompatible, anycompatible, integer) IS
'Pass in any two values that are, or can be coerced into, numbers, the number of rounding digits, and get back a rounded, safe division real result.';

在编写代码时，我将这些检查放在一起:

-- (real, int))
select '5.1/nullif(null,0)', 5.1/nullif(null,0)    as result union all 
select 'div_safe(5.1,0)', div_safe(5.1, 0)         as result union all

-- (0, 0)
select '0/nullif(0,0)', 5.1/nullif(null,0)         as result union all 
select 'div_safe(0, 0)', div_safe(0, 0)            as result union all

-- (int, int)
select '5/nullif(8,0)::real', 5/nullif(8,0)::real  as result union all 
select 'div_safe(5,8)', div_safe(5, 8)             as result union all

-- (string, int)
select 'div_safe(''5'',8)', div_safe('5', 8)       as result union all
select 'div_safe(''8'',5)', div_safe('8', 5)       as result union all

-- Rounding: Have to convert real result to numeric to pass it into ROUND (numeric, integer)
select 'round(div_safe(10,3)::numeric, 2)', 
        round(div_safe(10,3)::numeric, 2)           as result union all
        
-- Pass a third parameter to specify rounding:
select 'div_safe(20,13,2)', div_safe(20, 13, 2)     as result


+-----------------------------------+--------------------+
| ?column?                          | result             |
+-----------------------------------+--------------------+
| 5.1/nullif(null,0)                | NULL               |
| div_safe(5.1,0)                   | NULL               |
| 0/nullif(0,0)                     | NULL               |
| div_safe(0, 0)                    | NULL               |
| 5/nullif(8,0)::real               | 0.625              |
| div_safe(5,8)                     | 0.625              |
| div_safe('5',8)                   | 0.625              |
| div_safe('8',5)                   | 1.600000023841858  |
| round(div_safe(10,3)::numeric, 2) | 3.33               |
| div_safe(20,13,2)                 | 1.5399999618530273 |
+-----------------------------------+--------------------+

最后一行在我看来是错误的，它应该四舍五入到1.54。我发现我在进行其他测试之一时会出现这种行为。具体来说:

select '5/nullif(8,0)::real', 5/nullif(8,0)::real  as result union all 

如果没有这个，最后一行将按预期返回 1.54。

有人可以透露一下发生了什么吗？这与any兼容与UNION ALL的组合有关吗？我错过了一些非常简单的事情？

而且，如果有人知道的话，将来是否有可能将 anynum 添加为伪类型？

有关不一致输出的后续工作

我已经得到了对我原来的问题的有用答案(谢谢!)，并且正在跟进后续问题。即，为什么我的函数在返回数据之前对数据进行四舍五入，然后在最终结果中更改该值。它认为我在这里缺少一些基本的东西，而且它并不明显。我认为我需要确认正在调用该函数的正确版本，并RAISE NOTIFICATION 来获取值，如方法内部所示。这个新版本是 div_safe_p (anycompany,anycompany,integer) : real，并且是用 PL/PgSQL 编写的:

------------------------------
-- Rounding
------------------------------
drop function if exists tools.div_safe_p(anycompatible,anycompatible,integer);

CREATE OR REPLACE FUNCTION tools.div_safe_p(
    numerator    anycompatible,
    denominator  anycompatible,
    rounding_in  integer)

RETURNS real

AS $BODY$

DECLARE
  result_r    real := 0;

BEGIN

   SELECT ROUND(numerator/NULLIF(denominator,0)::numeric, rounding_in)::real INTO result_r;

   RAISE NOTICE 'Calling div_safe_p(%, %, %) : %', numerator, denominator, rounding_in, result_r;

   RETURN result_r;

END
$BODY$
  LANGUAGE plpgsql;

COMMENT ON FUNCTION tools.div_safe_p (anycompatible, anycompatible, integer) IS
'Pass in any two values that are, or can be coerced into, numbers, the number of roudning digits, and get back a rounded, safe division real result.';

这是一个示例调用和输出:

select  5/nullif(8,0)::real union all
select div_safe_p(10,3, 2)::real

+--------------------+
| ?column?           |
+--------------------+
| 0.625              |
| 3.3299999237060547 |
+--------------------+

div_safe_p 的结果似乎被转换为 double，而不是实数。检查RAISE NOTICE控制台输出，函数返回3.33:

NOTICE:  Calling div_safe_p(10, 3, 2) : 3.33

是的，这个3.33显示为3.3299999237060547。我不清楚为什么该值会根据函数返回的方式进行修改。我也无法通过手动转换值来重现转换。 select 3.33::real 和 select 3.33::double precision 都返回 3.33。

另一个变体，与原始版本相同，除了没有 ::real 类型转换:

select  5/nullif(8,0) union all
select div_safe_p(10,3, 2)

+----------+
| ?column? |
+----------+
| 0        |
| 3.33     |
+----------+

正如已经回答的那样，看起来遇到的第一个值正在指导列键入。然而，我很困惑为什么这会改变函数本身的行为。或者，至少改变输出的解释方式。

如果这听起来不错……也许确实如此。当我遇到无法解释的特殊情况时，我希望弄清楚发生了什么，以便我可以预测 future 更复杂的示例并对其进行故障排除。

感谢您的启发!

Answer 1

这符合 type resolution rules for UNION 的预期。 :

Select the first non-unknown input type as the candidate type, then consider each other non-unknown input type, left to right.

现在第一个非 NULL 数据类型是 double (请参阅 type resolution rules for operators )，因此所有结果都会转换为 double ，从而导致不精确性可见。如果没有该测试，结果的类型为 real，因此 PostgreSQL 显示的数字足够少以隐藏不精确性。

使用 pg_typeof 函数来显示数据类型很有用，这将清除问题:

SELECT pg_typeof(v)
FROM (SELECT NULL
      UNION ALL
      SELECT 2::real / 3::real
      UNION ALL
      SELECT pi()) AS t(v);

    pg_typeof     
══════════════════
 double precision
 double precision
 double precision
(3 rows)