But there’s life in the old dog yet. Postgres stands up rather well in benchmarks and if you’re going to have all your eggs in one basket, a relational database which also supports JSON is a fairly convenient basket.
So that got me thinking … when we talk to an SQL database through an ORM, we’re turning a bunch of operations on objects into a human readable query language, then turning that back into a query plan. Why?
Have a look for a moment at this description from src/backend/executor/README:
The executor processes a tree of “plan nodes”. The plan tree is essentially a demand-pull pipeline of tuple processing operations. Each node, when called, will produce the next tuple in its output sequence, or NULL if no more tuples are available.
Does that not sound like a more pleasant data structure to deal with than some daft pseudo-human-parseable string?
Postgres already contains code to bind a TCP socket and talk a “libpq” wire format. Rather than reinvent that particular wheel, it’d make sense to extend the protocol to support a new message which skips right around the query preparation and straight into the executor. Some kind of platform-neutral representation of that plan node tree would also be needed.
Try to actually make this happen! If nothing else, delving into the guts of Postgres is very educational. Unlike reading the source code of most projects, which feels like descending into the sewers beneath Ankh-Morpork, reading the source code of Postgres seem like ascending into the hidden spaces of some great architectural work.