> Surprises me too. I was under the (incorrect) impression that isnull
> was standard.
If it is, my books don't bother mentioning it. It would be pretty easy
to implement, if it *is* standard, since it is just a subset of
COALESCE() behavior.
But I'm a bit worried about the recent trend toward coding in
non-standard extensions as *alternatives* to standards-based behavior
just because a specific product has it. I know it's convenient for some,
but there are *lots* of products which have these kinds of things, each
in a different way, and at some point we would collapse under the weight
of trying to be all things at once.
Not naming any names, but *$ products seem to be the worst violators of
the simplest standards. One might ascribe this to simple incompetence,
except for their no-longer-in-doubt agenda of subverting standards in a
so-far-successful drive for market dominance. For example, Access
produces code of the form val = NULL
as an equivalent to the SQL92-standard val IS NULL
Where my Date book has a sentence:
"It is not possible to specify NULL explicitly as an operand of a
conditional expression - e.g., 'WHERE X = NULL' is illegal."
We now have a parser which violates that, for the sake of Access
compatibility. Of course, we do support another extension to SQL92 which
violates another rule in the same area:
"It is not possible to specify NULL explicitly as a select-item -- e.g.,
'SELECT NULL' is illegal."
Oh well. otoh, perhaps some of this would be legal for SQL3, which has a
somewhat more developed concept of NULL...
- Tom