> > Why? The "=" operator in an UPDATE statement
> > doesn't mean "equals", it means "becomes".
> >
> > Hence, FIELD <becomes operator> 5 or
> > FIELD <becomes operator> NULL
>
> The difference being that first you assign a value, and then a state.
>
> Now on the one hand, the SQL standard stresses that "state" and
> "value" are such different concepts that we really, really mustn't use
> the same equality operator for them (hence '=' for value comparison
> and 'is' for state comparison)...
>
> ...but when we're talking assignment, all of a sudden it's no problem
> to use the same operator to assign a value and a state. That's
> inconsistent.
>
> By the way, this has nothing to do with the fact that in SQL the
> equality operator happens to be the same as the assignment operator.
>
> Another inconsistency is found in statements like:
>
> insert into Dogtable ( Name, IQ, Sound )
> values ( 'Pluto', NULL, 'Woof' );
>
> Er? NULL a *value* ?
>
> But, as I said, we'll have to live with it...
>
>
> Greetings,
> Paul Vinkenoog

My observation is driven by the number of people who are migrating from
MySQL and other databases where it IS legal to test for NULL with the
equality operator. At times I think that sticking to a "standard" is making
us look like we are out of step with everyone else and certainly out of step
with people's expectations. Oracle and MS might be bad at some things but
they don't let standards per se drive there implementation. We all know that
they diverge frequently from the standard.
It's sort of like the "rules" of spelling, sooner or later words get spelt
differently because people want them to be spelt differently. They think
it's easier or nicer or just that the old way doesn't make sense any more.
Alan