The documentation for PL/pgSQL says, that declaration and assignment to variables is done with :=
.
But a simple, shorter and more modern (see footnote) =
seems to work as expected:
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
Please note, that Pl/pgSQL can distinguish assignment and comparison clearly as shown in the line
WHILE NOT i = 25 LOOP
So, the questions are:
=
instead of :=
?Edit / Footnote:
Please take the "more modern" part with a wink like in A Brief, Incomplete, and Mostly Wrong History of Programming Languages:
1970 - Niklaus Wirth creates Pascal, a procedural language. Critics immediately denounce Pascal because it uses "x := x + y" syntax instead of the more familiar C-like "x = x + y". This criticism happens in spite of the fact that C has not yet been invented.
1972 - Dennis Ritchie invents a powerful gun that shoots both forward and backward simultaneously. Not satisfied with the number of deaths and permanent maimings from that invention he invents C and Unix.
In PL/PgSQL parser, assignment operator is defined as
assign_operator : '='
| COLON_EQUALS
;
This is a legacy feature, present in source code since 1998, when it was introduced - as we can see in the PostgreSQL Git repo.
Starting from version 9.4 it is oficially documented.
This idiosyncrasy - of having two operators for same thing - was raised on pgsql users list, and some people requested it to be removed, but it's still kept in the core because fair corpus of legacy code relies on it.
See this message from Tom Lane (core Pg developer).
So, to answer your questions straight:
Didn't I find some section in the docs which mention and/or explains this?
You did not find it because it was undocumented, which is fixed as of version 9.4.
Are there any known consequences using = instead of :=.
There are no side consequences of using =, but you should use := for assignment to make your code more readable, and (as a side effect) more compatible with PL/SQL.
Update: there may be a side consequence in rare scenarios (see Erwin's answer)
UPDATE: answer updated thanks to input from Daniel, Sandy & others.