Agreed about undocumented behavior (actually there is a *lot* of undocumented behavior in PostgreSQL as I have slowly found out-- if you want to see a lot of it, go look at the pg_dump source code).
However = as assignment is particularly odd to me for two reasons. First it is not ambiguous but it leads to difficult to read constructs, like this:
CREATE OR REPLACE FUNCTION cmp(in_left text, in_right text) returns bool language plpgsql as
$$
DECLARE out_var bool;
BEGIN
out_var = in_left = in_right;
return out_var;
END;
$$;
Secondly it is way too easy for a beginner to accidently use = as an assignment operator. This can lead to odd, difficult to understand, bugs. If it is going to be legacy behavior at least we should consider raising a warning.
Best Wishes,
Chris Travers
On Fri, May 31, 2013 at 11:36 PM, David Johnston <polobo@xxxxxxxxx> wrote:
Tom Lane-2 wrote
> Stephen Frost <
> sfrost@
> > writes:
>> * Moshe Jacobson (
> moshe@
*Nutshell*
> ) wrote:
>>> Any PG committers who can change this in 9.3?
>
>> It will certainly not be changed for 9.3.
>
> IMO, if we do anything about this at all, it should be to document the
> "=" option not remove it. If we change it, the squawks from people who
> were (perhaps unintentionally) depending on the current behavior will
> outnumber the plaudits from people who think that such a change is a
> good idea by several orders of magnitude.
>
> regards, tom lane
In short; I generally do not like undocumented behavior - especially for
something that an inexperienced user is going to encounter without even
thinking about it. "=" for assignment is so common that you need to decide
to either allow it or not; many people will use it just to see if it works
and then, if it does not, will RTFM and learn that they should instead be
using ":=". GET DIAGNOSTICS is simply a special-form of the basic
assignment and thus should have the same rules and documentation.
The fact that we talking about documenting this as opposed to making it work
reinforces this choice. Time will only make the problem worse. Either
there is a strong enough argument NOW to do away with this dual-usage of "="
and we define the plan of action starting with warnings in 9.4 OR we
document it for 9.3 (and, really, back to all supported versions). Crap or
get off of the toilet.
*Exposition*
I have not gone and looked but I know there is some form of the "check
function" routine floating around here and that routine could have a "strict
assignment" option for those who want that safety check.
That said, in the OP's example the code intended to use assignment and
correctly did so. I am having trouble finding any example, let alone a
compelling one, where allowing "=" to have both assignment and equality
meanings would lead to silent bugs. This may be a lack of imagination on my
part. The fact that assignment cannot occur in an _expression_ while equality
must is the reason for the difficulty. It is when assignment can occur in
an _expression_ (and thus, like equality, has a return value) that ambiguity
(and thus bugs) arises.
Pavel brings up the point of cross-language compatibility and learning and
in general I would agree but, and again because of the exclusive syntax
zones for assignment and equality in the "PL/PGSQL" language said
compatibility can be something achieved at a higher level - plus I would
think having more options would work in favor. If the issue is people
moving their PostgreSQL code to Oracle then I am not sure whether I'd change
the language to make that work more easily - I'd much rather keep everyone
who has been using the "=" for assignment happy and let higher level
compatibility tools handle the conversion.
I agree with documenting the "GET DIAGNOSTICS var := item;" syntax and in
fact from a purely OCD standpoint wonder why non-diagnostic assignment is
documented for ":=" while diagnostic assignment is documented for "=". The
"GET DIAGNOSTICS" part is a modifier for the statement but doesn't magically
turn the construct into an _expression_.
David J.
P.S. Undocumented behavior should be considered "not yet documented"
behavior. It isn't worth documenting everything but if an issue or
confusion arises then at least document "we allow - for the following
reasons - this behavior but recommend you do not rely on it - for the
following reasons". The visibility of said documentation should be directly
proportional to the level of experience of the user that will encounter said
behavior.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Strange-behavior-of-as-assignment-operator-tp5757205p5757631.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
