> > Don't know how or if we want to proceed with a bare "NULL" clause.
> > Should we bother with a special case of _only_ NULL in a
> > declaration, as in Bruce's patch?
> My patch is clearly wrong. The NULL should be parallel to NOT NULL,
> and ought just to be ignored (since NULL is the default). I think
> it's worth doing (as the book says, NULL may not be the default on
> your system, and anyway, it's always better to specify just for
> clarity).
> I think explicitly specifying NULL is probably good practice, so it
> should be supported.
Maybe (SQL92 is full of inconsistant/non-symmetric features), but you
will need to figure out how to do it without shift/reduce conflicts in
the grammar. The fact that they are there means that either it is
impossible to unambiguously parse the allowed syntax, or that the
grammar definition in the yacc language needs to be restructured a bit.
It isn't obvious to me how to restructure for this case; I've fixed this
kind of problem in other parts of the grammar and the tricks I used
there don't look usable here.
I know it isn't helpful to always fall back on "big philosophy" when you
are proposing a small fix/improvement, but we should think about how
much clutter we want to put in to the grammar. The "bare NULL" is
apparently _not_ SQL92 (it does not appear in the BNF definitions in my
SQL book by Date).
I'd like us to think about limiting the extensions to SQL92 in favor of
extending the grammar toward Postgres' OR features. Just a thought...
- Tom
