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 | CAFj8pRAjCJEHsHOQnXbu_EH8A3ov5+cFwh+zOhWt7zfj8Kb=Hw@mail.gmail.com Whole thread Raw |
In response to | Re: Strange behavior of "=" as assignment operator (David Johnston <polobo@yahoo.com>) |
List | pgsql-general |
2013/6/1 David Johnston <polobo@yahoo.com>: > 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. > yes, I agree - this should be documented and there should be warning about a possible problems in future. > 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. just note to GET DIAGNOSTICS statement It is ANSI/SQL statement and there is exact definition GET DIAGNOSTICS var = item, ... So support anything else is creating own SQL extension > > 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: