I just noticed that 'ISNULL' 'NOTNULL' 'NOT NULL' are not even mentioned at all. Those would be unary suffix operators that mean the same as 'IS NULL', 'IS NOT NULL' as appropriate.
e.g.
```
sqlite> select 1 isnull;
0
sqlite> select null isnull;
1
sqlite> select null isitnull; --> a column alias, not an operator
sqlite> select 1 notnull;
1
sqlite> select null notnull;
0
sqlite> select 1 nonnull; --> valid syntax but not NONNULL;
1
sqlite> select 11 nonnull; --> a column alias, not an operator
11
sqlite> select 11 notnull;
1
sqlite> select 11 not null;
1
sqlite> select 11 non null; --> no syntax hazard with this form
Error: near "null": syntax error
sqlite> select null not null;
0
sqlite> select 11 not 1; --> NOT 1 gives syntax error not semantic error
Error: near "1": syntax error
```
Note that the grammar does not treat "1 not null" as binary operator NOT applied to 1 and null. Though it could have done so (with anything on the right but null being a semantic error). Instead
```
expr(A) ::= expr(A) NOT NULL. {A = sqlite3PExpr(pParse,TK_NOTNULL,A,0);}
```
Treats it as a two-word unary suffix; which frankly makes the most sense.
The other alternative, treating "NOT NULL" as a single lexeme would cause more problems because `x IS NOT NULL` would have an irregular parse. In any case discussing decisions the grammar did not make will in no way simplify the documentation, so forgive me for indulging in trivia.
FWIW I'm not a fan of these forms because of the syntax hazard:
```
select ? nonnull;
```
Which is an easy typo that would not be quickly spotted and is not a syntax error.
```
select ? is not null;
```
Does not have this problem. But again, such warnings may have a place somewhere but probably not in this chapter. These forms, hazardous or no, are part of generally accepted SQL.