Re: Strange behavior of "=" as assignment operator - Mailing list pgsql-general
From | Pavel Stehule |
---|---|
Subject | Re: Strange behavior of "=" as assignment operator |
Date | |
Msg-id | CAFj8pRBSh42f6VcoCuYhAd8eup-inADHnq6i1M+hOEBcrstRUw@mail.gmail.com Whole thread Raw |
In response to | Re: Strange behavior of "=" as assignment operator (Chris Travers <chris.travers@gmail.com>) |
List | pgsql-general |
2013/6/1 Chris Travers <chris.travers@gmail.com>: > 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; > $$; > good example > > 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@yahoo.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@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general > >
pgsql-general by date: