Hi,

> >> 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.
>
> > Nope, it isn't...
> >
> > FIELD becomes 5
> > FIELD becomes NULL
> >
> > Sounds fine to me for an assignment.
>
> FIELD is 5
> FIELD is NULL
>
> sound just as fine to me for a test.

Except that "is" is used for states :-) and "equals" for values.

> The point is, what do you mean when you say: FIELD becomes X ?
> Because the field as such doesn't become 5, or NULL, or whatever.
>
> In the first example, you mean that the field VALUE becomes 5.
> In the second, that the field STATE becomes NULL.
>
> So again, if you're quite happy with using
>
> FIELD = 5
> FIELD = NULL
>
> when they really mean:
>
> FIELD.value becomes 5
> FIELD.state becomes NULL

Yes.

> why not use
>
> FIELD = 5
> FIELD = NULL
>
> when you want to test whether:
>
> FIELD.value equals 5
> FIELD.state equals NULL

Because I'm used to "is" :-)

As the .value or .state doesn't exists, the distinction
comes via equals (=) or a state check (is). There you
have it, it's because the .state/.value doesn't exist :-)

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com