RE: [HACKERS] Re: [QUESTIONS] Practical SQL Handbook - demo scrip t for postgreSQL

Started by Jackson, DeJuanover 27 years ago1 messages
#1Jackson, DeJuan
djackson@cpsgroup.com

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