Malte Schwarzkopf

Oh, sorry, I overlooked #24 (although that fails to build). I guess this PR can be closed if #24 merges.

Thank you! :+1: This looks good. I actually agree with @glittershark's more extensive proposed change above. We should make that change, so that `SELECT` queries without tables are more natural....

Yes! I've been meaning to add support for more descriptive syntax errors for a while, but never got around to it. Independently, I believe `nom`'s story for parse error handling...

(Though I like the changed you linked; we can certainly merge that one right away.)

Yeah, I think that's perhaps the best plan. `Literal` is never stored in large volumes, so wasting some memory on it is fine (unlike with `DataType`). This kind of slightly...

Agreed -- and support for `/* ... */`-style comments would also be nice. The best way to do this is perhaps to pre-process the entire input string with a parse...

Good catch -- I actually independently ran into this issue last week (also parsing MySQL dumps) and made a mental note to fix it! I originally looked at `nom::escaped_transform` for...

I think we have all of them supported now, thanks to @lovasoa's work :+1:

Thanks, I'll take a look at changing this. Should just be a matter of emitting an `Operator::Is` instead of `Operator::Equals`, I think.

Oh, duh -- I missed this PR. Will take a look to see if your solution is better than mine (which was a quick hack to get a query to...