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 <pol...@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 >
