被遗忘的赋值运算符“=”和司空见惯的“：=”-解网

问：

PL/pgSQL 的文档说，变量的声明和赋值是用 . 但是一个简单、更短、更现代^{（见脚注）}似乎按预期工作：:==

    CREATE OR REPLACE FUNCTION foo() RETURNS int AS $$
    DECLARE
      i int;
    BEGIN
      i = 0;  
      WHILE NOT i = 25 LOOP
          i = i + 1;
          i = i * i;
      END LOOP;
      RETURN i;
    END;
    $$ LANGUAGE plpgsql;

    > SELECT foo();
    25

请注意，Pl/pgSQL 可以清楚地区分赋值和比较，如行所示

      WHILE NOT i = 25 LOOP

所以，问题是：

我没有在文档中找到一些提到和/或解释这一点的部分吗？
是否有任何已知的后果使用代替？=:=

编辑/脚注：

请眨眨眼，“更现代”的部分，就像在《编程语言的简短、不完整和大多错误的历史》中一样：

1970 年 - Niklaus Wirth 创建了 Pascal，一种程序语言。评论家立即谴责 Pascal，因为它使用了 “x ：= x + y” 语法而不是更熟悉的类似 C 的“x = x + y”。这种批评尽管 C 尚未被发明，但还是发生了。

1972年 - 丹尼斯·里奇（Dennis Ritchie）发明了一种强大的枪，可以向前射击和向后同时。对死亡人数不满意以及他发明的 C 和 Unix 的发明造成的永久残缺。

PostgreSQL PLPGSQL 赋值运算符冒号等于

在你的回答中，你写了关于冒号等于的这段话：“它计划被移除，但仍然保留在里面，因为有些人依赖它”。这应该意味着，如果他们继续执行计划，使用冒号相等可能会导致问题。但是，在回答的最后，你写了“使用 = 没有附带后果，但你应该使用：= 进行赋值，以使你的代码面向未来。这两种说法不是相互矛盾吗？

1赞 filiprem 6/19/2015

@Sandy，对。我宁愿说“在被标记为过时多年后，它可以被删除。关于“副作用”：可能有一些。不频繁，但有可能。无论如何，删除这个小陷阱不值得破坏遗留代码。我敢打赌，我们至少会拥有几年。

2赞 Daniel Vérité 6/22/2015

从版本 9.4 开始，它记录为赋值语法，因此占主导地位的选项是完全支持赋值。variable { := | = } expression=

41赞 Erwin Brandstetter 2/25/2014 #4

问题1

这终于被添加到了 Postgres 9.4 的官方文档中：

对 PL/pgSQL 变量的值赋值写成：

variable { := | = } expression;

[...]可以使用 equal （）代替 PL/SQL 兼容。=:=

问题2

是否有任何已知的后果使用代替？=:=

是的，我有一个后果严重的案例：使用命名参数的函数调用 - 这是相关的，但不完全相同。

严格来说，在这种情况下，区别是在 SQL 代码中进行的。但对于毫无戒心的程序员来说，这是一种学术上的差异。¹

考虑以下函数：

CREATE FUNCTION f_oracle(is_true boolean = TRUE)  -- correct use of "="
  RETURNS text
  LANGUAGE sql AS
$func$
SELECT CASE $1
       WHEN TRUE  THEN 'That''s true.'
       WHEN FALSE THEN 'That''s false.'
       ELSE 'How should I know?'
       END
$func$;

请注意函数定义中的正确用法。这是语法的一部分 - 采用 SQL 赋值的样式。^{阿拉伯数字}=CREATE FUNCTION

使用命名表示法的函数调用：

SELECT * FROM f_oracle(is_true := TRUE);

Postgres 标识为参数分配，一切都很好。但是：:=

SELECT * FROM f_oracle(is_true = TRUE);

由于 = 是 SQL 相等运算符，因此 Postgres 在调用语句的上下文中解释为 SQL 表达式，并尝试在将结果作为未命名的位置参数传递之前对其进行评估。它在外部作用域中查找标识符。如果找不到：is_true = TRUEis_true

ERROR:  column "is_true" does not exist

这是幸运的情况，幸运的是，也是常见的情况。

When can be found in the outer scope（并且数据类型兼容）是一个有效的表达式，其结果被函数接受。不会发生错误。显然，这是程序员使用 SQL 相等运算符的意图......is_trueis_true = TRUEboolean=

此 db<>fiddle 演示了该效果。
_{旧 sqlfiddle}

如果您不知道和之间的区别，则很难调试。
始终使用正确的运算符。=:=

¹ 在函数调用中使用命名表示法时，只有 ：= 是正确的赋值运算符。这适用于所有语言的函数，而不仅仅是 PL/pgSQL，直到第 9.4 页。见下文。

² 可以使用 =（或）来定义函数参数的默认值。这与手头的问题没有任何关系。它只是非常接近不正确的用例。DEFAULT

Postgres 9.0 - 9.4：从`:==>`

分配给命名函数参数的 SQL 标准是 =>（Oracle 的 PL/SQL 使用它。Postgres 无法执行相同的操作，因为运算符以前是未保留的，因此它改用 PL/pgSQL 的赋值运算符。随着 Postgres 9.0 的发布，已弃用用于其他目的。发行说明：:==>

不推荐使用 => 作为运算符名称（Robert Haas）

PostgreSQL 的未来版本可能会拒绝此运算符名称完全，以便支持 SQL 标准表示法函数参数。目前，它仍然是允许的，但定义此类运算符时，将发出警告。

如果您应该用于其他用途，请停止并停止。它将来会坏掉。=>

Postgres 9.5：立即使用`=>`

从此版本开始，将使用 SQL 标准运算符 =>。仍支持向后兼容。但是在不需要在非常旧的版本上运行的新代码中使用标准运算符。:=

记录在手册的“使用命名表示法”一章中。
这是 GIT 中的带有解释的提交。

这适用于函数调用（SQL 作用域）中的命名参数赋值，不适用于 plpgsql 代码中的赋值运算符，后者保持不变。:=

上一个：Data.Table 对象在函数中分配了：= 未打印

下一个：PHP 中的引用赋值运算符，=&

被遗忘的赋值运算符“=”和司空见惯的“：=”

The forgotten assignment operator "=" and the commonplace ":="

评论

评论

评论

评论

问题1

问题2

Postgres 9.0 - 9.4：从:==>

Postgres 9.5：立即使用=>

Postgres 9.0 - 9.4：从`:==>`

Postgres 9.5：立即使用`=>`