For my money, I'd prefer to have a smaller, faster parser that worked correctly on correct input at the expense of not catching all possible syntax errors on silly input. There is a definite trade-off here, and I could see where a totally complete parser that caught every possible error in SQL grammer might be twice the size of the entire SQLite code base.
Of course, you don't want an SQL syntax typo to trash your database either, without warning. I'm assuming the SQLite developers have made reasonable decisions about which parsing errors are important, and which aren't. Jim On 5/26/09, John Machin <sjmac...@lexicon.net> wrote: > > 1. SQLite allows NULL as a column-constraint. > > E.g. CREATE TABLE tname (col0 TEXT NOT NULL, col1 TEXT NULL); > > The column-constraint diagram doesn't show this possibility. > > Aside: The empirical evidence is that NULL is recognised and *ignored*; > consequently there is no warning about sillinesses and typoes like in > these examples of column-def: > col1 INTEGER NOT NULL NULL > col1 INTEGER NOTE NULL -- type="INTEGER NOTE", constraint="NULL" > > 2. According to the diagram for foreign-key-clause, there is no "express > track" which allows skipping both "ON DELETE|UPDATE|INSERT etc" and > "MATCH name". However SQLite does permit all of that to be skipped. > > E.g. CREATE TABLE tname(col0 TEXT PRIMARY KEY, col1 TEXT REFERENCES > ftable(fcol)); > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Software first. Software lasts! _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
