Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id TAA99281
	for <pgsql-sql@postgreSQL.org>; Mon, 15 Nov 1999 19:51:09 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA19819;
	Mon, 15 Nov 1999 19:50:17 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: pgman@candle.pha.pa.us (Bruce Momjian), goran@kirra.net,
	pgsql-sql@postgreSQL.org
Subject: Re: [SQL] NULL 
In-reply-to: Your message of Tue, 16 Nov 1999 00:48:21 +0100 (MET)
	<m11nVrB-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Mon, 15 Nov 1999 19:50:16 -0500
Message-ID: <19817.942713416@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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...

			regards, tom lane