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 David Johnston <polobo@xxxxxxxxx>:
> 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@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