On Mon, Nov 29, 1999 at 10:13:59PM -0500, Bruce Momjian wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > wieck@debis.com (Jan Wieck) writes:
> > > I can't see any shift/reduce conflicts if I place a
> > > | NULL_P
> > > case into the ColConstraintElem: definition right between the
> > > | DEFAULT b_expr
> > > and
> > > | NOT NULL_P
> > > cases. Could it be that this reason is out of date?
> >
> > Could be. I remember tweaking the ColConstraint grammar to avoid
> > shift-reduce conflicts with NOT NULL, and it might be that that got
> > rid of the problem with NULL as well.
> >
> > It's still not legal under the SQL92 spec, though, and I'd hate to see
> > us give up anything else in order to allow a content-free NULL spec to
> > be added...
>
> OK, I assume we are going to dis-allow NULL as a column constraint. We
> could allow it but emmit a notice.
My recollection of this thread was that no one found any reason to
dis-allow NULL as a column (pseudo)constraint, other than it not being
in the SQL92 standard. In particular, I understood Jan to say that he
tried it, and received no shift/reduce conflicts from flex. I think we
all agree with Tom that there's no need for it, so we shouldn't give up
anything else to get it, but several people mentioned having it easied
porting from Sybase, or some other commercial db, where the machine
generated DDL dumps include the NULL constraints. So, class it with the
other compatability hacks, and include it, perhaps?
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005