被遗忘的赋值运算符“=”和常见的“：=”

Question

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

所以，问题是：

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

编辑/脚注：

请像 A Brief, Incomplete, and Mostly Wrong History of Programming Languages 一样眨眼看“更现代”的部分：

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

1972 - 丹尼斯·里奇发明了一种强大的枪，可以向前射击 并同时倒退。对死亡人数不满意 他发明了 C 和 Unix。

Answer 1

阅读 Postgresql 9 文档：

This page 将“=”列为运算符优先级表中的赋值运算符。

但奇怪的是this page（赋值运算符文档）没有提到它。

Answer 2

我自己的问题的部分答案：

PL/pgSQL 部分Obtaining the Result Status 显示了两个使用特殊语法的示例：

GET DIAGNOSTICS variable = item [ , ... ]; 
GET DIAGNOSTICS integer_var = ROW_COUNT;

我尝试了:= 和=，它们都可以。

但是GET DIAGNOSTICS 是一种特殊的语法，所以有人会争辩说，这也不是一个正常的 PL/pgSQL 赋值操作。

Answer 3

在PL/PgSQL解析器中，赋值运算符定义为

assign_operator : '='
                | COLON_EQUALS
                ;

这是一项遗留功能，自 1998 年引入源代码以来一直存在 - 正如我们在 PostgreSQL Git repo 中看到的那样。

从 9.4 版开始是oficially documented。

这种特性——同一事物有两个运算符——在 pgsql 用户列表中被提出，有些人要求将其删除，但它仍保留在核心中，因为遗留代码的公平语料库依赖于它。

看到这个message from Tom Lane (core Pg developer)。

所以，直接回答你的问题：

我没有在文档中找到一些提到和/或解释的部分 这个？

你没有找到它，因为它没有记录，从 9.4 版开始修复。

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

使用 = 没有副作用，但您应该使用 := 进行赋值以使您的代码更具可读性，并且（作为副作用）更兼容使用 PL/SQL。

更新：在极少数情况下可能会有副作用（参见 Erwin 的回答）

---

更新：感谢 Daniel、Sandy 和其他人的意见更新了答案。

Answer 4

第一季度

这终于是added to the official documentation with Postgres 9.4：

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

variable { := | = } expression;

[...] 可以使用相等 (=) 代替符合 PL/SQL 的 :=。

第二季度

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

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

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

考虑函数：

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

旁白：注意在函数定义中正确使用=。这是CREATE FUNCTION 语法的一部分——以 SQL 赋值的形式。²

使用命名符号的函数调用：

SELECT * FROM f_oracle(is_true := TRUE);

Postgres 将:= 识别为参数分配，一切正常。 但是：

SELECT * FROM f_oracle(is_true = TRUE);

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

ERROR:  column "is_true" does not exist

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

当is_true 可以在外部范围内找到时（并且数据类型兼容），is_true = TRUE 是一个有效的表达式，其结果为boolean，函数接受。不会发生错误。显然，这是程序员使用 SQL 相等运算符= ...

的意图

这个SQL Fiddle 演示了效果。

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

---

¹ 使用named notation in function calls 时，只有:= 是正确的赋值运算符。这适用于所有语言的函数，而不仅仅是 PL/pgSQL，直到并包括 pg 9.4。见下文。

² 可以使用=（或DEFAULT）来定义default values for function parameters。这与手头的问题没有任何关系。它非常接近错误的用例。

Postgres 9.0 - 9.4：从 := 转换到 =>

分配给命名函数参数的 SQL 标准是 =>（和 Oracle's PL/SQL uses it。Postgres 不能这样做，因为该运算符之前没有保留，所以它使用 PL/pgSQL 的赋值运算符 := 代替。随着 Postgres 9.0 的发布，不推荐将 => 用于其他目的。Per release notes：

不赞成使用 => 作为运算符名称 (Robert Haas)

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

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

Postgres 9.5：现在使用=>

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

• 记录在手册中，章节Using Named Notation。
• Here's the commit with explanation in GIT.

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