Search Postgresql Archives

Re: Strange behavior of "=" as assignment operator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2013/6/1 Chris Travers <chris.travers@xxxxxxxxx>:
> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxx)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
>


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux