> > > > The NULL contraint: PostgreSQL only allows NOT NULL (NULL being
> > > > the default). I altered the backend grammar for this one.
> > >
> > > Patch?
> >
> > OK. The patch to gram.y is almost certainly wrong: it's just a hack
> > to get NULL acceptable---it should surely go in the same place as
> the
> > check for NOT NULL.
>
> Yes, and no. Putting the grammar where you did disallows any other
> clauses, such as DEFAULT or CONSTRAINT, in the declaration. Trying to
> put it in the proper place results in shift/reduce conflicts, since it
> is ambiguous with other allowed syntax.
>
> btw, afaik this is not SQL92 anyway...
>
> > The floating point literal change is probably right, but it may
> break
> > things (it may well cause more things to be regarded as floats than
> > should be). Again, somebody who knows about this stuff definitely
> > needs to check.
> >
> > I hope this helps all the same.
>
> Yes it does! I've got a more general floating patch to apply, but
> would
> not have done it without your prompting. Discussion and proposals are
> how we progress. Good work.
>
> 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?
Continuing with the discussion/proposal theme: I vote yes for the bare
NULL if it can be done with a minimum of hassle. It would at the very
least improve compatibility with SYBASE AND MS SQL Server. I know that
these aren't goals, but it doesn't hurt to have it happen. Could
someone check the Create table syntax and see if it's SQL92 (I have a
suspicion that it is).
I'm not sure about the 'shift/reduce', but couldn't you interpret the
NULL not preceded by NOT in a CREATE TABLE /ALTER TABLE as an empty
string. I'm assuming here that the NOT NULL is treated as one token in
the grammar/parser.
-DEJ
