On 12/12/19, Warren Young <war...@etr-usa.com> wrote: > On Dec 12, 2019, at 6:08 AM, Mike King <making1...@gmail.com> wrote: >> >> ...I decided on a simple subset of >> SQL and then wrote a parser using a regex as the tokeniser. > > First, [SQL is not a regular language][1], so it probably cannot be > completely parsed by regexes. Not by a single regex without surrounding > logic, anyway. There’s probably valid SQL that will pass your regex but > give unwanted behavior. > > Second, you’re reinventing SQLite’s own authorizer, which runs based on the > output of SQLite’s own well-tested SQL parsing engine. (Which uses a proper > parser, not a regex.)
Excellent points. Nevertheless, I think you can make the case for using a home-grown regexp-based language restrictor *in addition to* the built-in SQLite authorizer. Layers of defense. So my advice to the Mr. King is not to take out his regexp-based language restrictor but rather to add in an additional layer based on the SQLite authorizer, for redundancy. During development and testing, there should be some means of turning each mechanism off separately so that the other can be tested, but in deployment both should be hard-wired on. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
