Writing a SQL database from scratch in Go
notes.eatonphil.com
Writing a SQL database from scratch in Go
1–10 of 55 posts
Re: Writing a SQL database from scratch in Go
#2Unexpected, but welcome, to see the first part in the series on here right now. I just published the second part [0] today, featuring binary expressions and WHERE filtering. It also updates the REPL to use a prettier table-printing library and a readline implementation.
The repo [1] has some additional bare notes on architecture and links to similar, more mature projects (primarily go-mysql-server and ramsql).
[0] https://notes.eatonphil.com/database-basics-expressions-and-...
Re: Writing a SQL database from scratch in Go
#3Probably the first article Ive ever read about lexical parsing with code that i have actually understood - and I dont even program in golang. Great job.
Re: Writing a SQL database from scratch in Go
#4Probably the first article Ive ever read about lexical parsing with code that i have actually understood - and I dont even program in golang. Great job.
Lexical analysis using these bespoke methods (writing the finite state machine) is so tedious and error prone. I don't have that much experience but I just went through crafting interpreters and replaced this same module with https://github.com/J-F-Liu/pom, which is a parser combinator library, and it was way easier.
Re: Writing a SQL database from scratch in Go
#5selectKeyword keyword = "select"
I don't work with Go, so this may be a requirement of the language that I don't know, but whenever I see lines like this, it automatically brings up the question why? --- do you really expect to need to rename the SELECT keyword? Especially when it's named "selectKeyword". Why not just use the string constant? Ditto for the others like "leftparenSymbol" --- I see there's explicit character constants in some of the other code too... it reminds me of the classic anti-pattern like "int five = 5;".
Also, you may find the full SQL grammars interesting to look through --- they are quite a bit more complex than the subset presented in the article: https://ronsavage.github.io/SQL/
Re: Writing a SQL database from scratch in Go
#6Probably the first article Ive ever read about lexical parsing with code that i have actually understood - and I dont even program in golang. Great job.
It's recursive-descent --- a pretty common and intuitive way to write a parser in general.
Re: Writing a SQL database from scratch in Go
#7selectKeyword keyword = "select" I don't work with Go, so this may be a requirement of the language that I don't know, but whenever I see lines like this, it automatically brings up the question why? --- do you really expect to need to rename the SELECT keyword? Especially when it's named "selectKeyword". Why not just use the string constant? Ditto for the others like "leftparenSymbol" --- I see there's explicit char…
The biggest reason to do this in Go is to approximate enums. Now anywhere the `keyword` type is used, it must be one of the ones specified there (or you'd have to cast a string).
Yep, it would be a little harder to implement all of the SQL spec in a single post. Maybe over time though.
Re: Writing a SQL database from scratch in Go
#8selectKeyword keyword = "select" I don't work with Go, so this may be a requirement of the language that I don't know, but whenever I see lines like this, it automatically brings up the question why? --- do you really expect to need to rename the SELECT keyword? Especially when it's named "selectKeyword". Why not just use the string constant? Ditto for the others like "leftparenSymbol" --- I see there's explicit char…
Another reason is that by providing an identifier for this string literal, misspellings of it can be detected by the compiler whereas there is nothing tying separate string literals together.
Re: Writing a SQL database from scratch in Go
#9selectKeyword keyword = "select" I don't work with Go, so this may be a requirement of the language that I don't know, but whenever I see lines like this, it automatically brings up the question why? --- do you really expect to need to rename the SELECT keyword? Especially when it's named "selectKeyword". Why not just use the string constant? Ditto for the others like "leftparenSymbol" --- I see there's explicit char…
The IDE will autocomplete selectKeyword but not "select".
Other type systems, like TypeScript, support string literal types, and in Typescript we generally would just define the keyword type to be a union of string literals and then use those string literals in the code.
But without string literal types, using a string constant gives the compiler more information it can use to make sure your code is correct. That's a useful thing to have.
Re: Writing a SQL database from scratch in Go
#10Probably the first article Ive ever read about lexical parsing with code that i have actually understood - and I dont even program in golang. Great job.
Lexical analysis using these bespoke methods (writing the finite state machine) is so tedious and error prone. I don't have that much experience but I just went through crafting interpreters and replaced this same module with https://github.com/J-F-Liu/pom , which is a parser combinator library, and it was way easier.
Parser combinators are neat. nom is my go-to now in Rust, it's nice not have to separate your lexer and parser in simpler grammars.