36 lines
1.5 KiB
Text
36 lines
1.5 KiB
Text
Communication with client (mainly processing client's input)
|
|
* understand and implement the postgres protocol
|
|
* setup of concurrent connections
|
|
* when client sends a query, we send it to the parser
|
|
|
|
Parsing can be started now
|
|
basically a function
|
|
String -> Result<RawOperationSyntax, ParsingError>
|
|
|
|
Validation of operation
|
|
When parsing gives you a raw syntax of an operation, it need not make sense (e.g. table doesn't exist)
|
|
So we need to validate it.
|
|
The output of the validation is
|
|
* a proper operation validated against the database schema
|
|
* reject when e.g. table doesn't exist, condition refers to non-existent column etc
|
|
* This phaze doesn't need access to runtime data (e.g. rows or indices), just the table schemas.
|
|
|
|
==========Locking of tables should happen here========
|
|
|
|
Interpretation:
|
|
Change the state of the table given the validated operation
|
|
|
|
Responding to the client
|
|
* with error messages
|
|
* with success message (after insert/delete etc)
|
|
* with rows
|
|
|
|
==========Lock on the table should be dropped here===========
|
|
|
|
Serialization/Desearilization to disk
|
|
There are two approaches
|
|
* one is incremental (and very hard), a storage engine where you have a huge database on disk
|
|
encoding something like a BTree, and then you have a small in-memory view (cache) on what's on the disk.
|
|
And you try to constantly keep these synced.
|
|
* the other is: when the server is shut down, just serialize the in-memory database state onto disk
|
|
in e.g. JSON. Trivial to implement.
|