3 ms·

I like this project! I think I've asked you about it supporting parquet before... I'll add it to my list of similar projects. Regarding goyacc and "usually", I

I like this project! I think I've asked you about it supporting parquet before... I'll add it to my list of similar projects. Regarding goyacc and "usually", I myself was curious about this years ago and asked on Stack Exchange: Do modern languages still use parser generators? [0]. Most of the time, major languages _do_ use hand-written parsers. Of course it may literally be the case that most other SQL projects in Go do use goyacc. My point is that in general, hand-written parsers are more common in real software than you might think. [0] https://softwareengineering.stackexchange.com/questions/250256/do-modern-languages-still-use-parser-generators/250264 https://softwareengineering.stackexchange.com/questions/2502...

cube2222 7y ago
Indeed, I remember! :) The parquet support is mostly ready as far as I know here https://github.com/cube2222/octosql/pull/153/ https://github.com/cube2222/octosql/pull/153/ but I haven't tested it myself yet. However, we'll surely have it ready for the "streaming" release which is planned for May/June. Regarding the parsing part, that's interesting. Though the cockroachdb parser is a _great_ lecture about how to add nice error messages with goyacc. (You add a special error token which captures anything after a syntax error, so the parser doesn't break down. At least something around this, haven't yet dived deep into it.) Though I know Go itself uses a handwritten parser.