On 27/05/2009 12:33 AM, Jim Wilcoxson top-posted: > 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.
Firstly, none of the examples that I gave are syntactically incorrect. Secondly, a compiler that doesn't reject ill-formed syntax should not be seen after first semester CS101 -- the very idea is a nonsense. Thirdly, all I'm asking for is a few more lines to make the diagrams accord with what the SQL compiler is already doing. > 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. Which is why you test your software ... so col1 is not supposed to permit NULLs so you need to test it whether you wrote the syntactically correct "col1 INTEGER NOTE NULL, ..." or the equally syntactically correct "col1 INTEGER, ..." -- both being practically wrong. > I'm assuming the SQLite developers have made > reasonable decisions about which parsing errors are important, and > which aren't. I hope they don't have any /parsing/ errors at all. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
