Re: Strange behavior of "=" as assignment operator

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(at)yahoo(dot)com> wrote:

> Tom Lane-2 wrote
> > Stephen Frost <
>
> > sfrost@
>
> > > writes:
> >> * Moshe Jacobson (
>
> > moshe@
>
> > ) 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
>
> *Nutshell*
>
> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>