Rowan Marshall

Every SQLite output mode explained

Rowan Marshall — Wed, 04 Mar 2026 00:00:00 +0000

SQLite has many viewing modes it can output, and I have difficulty remembering them all and what to use when, so I’m posting this as a public memory for myself and anyone else finding themselves googling “sqlite all modes example” a lot.

Column

Good for eyeballing data interactively - aligns values into readable columns.

.mode column

id  name   email
--  -----  -------------------
1   Alice  alice@example.com
2   Bob    bob@example.com

List

Useful for piping output into shell scripts or other tools that split on a delimiter.

.mode list

1|Alice|alice@example.com
2|Bob|bob@example.com

Line

Handy when you have wide rows and want to read each field on its own line.

.mode line

   id = 1
 name = Alice
email = alice@example.com

   id = 2
 name = Bob
email = bob@example.com

CSV

Use this when you want to export data to a spreadsheet or another tool that accepts CSV.

.mode csv

1,Alice,alice@example.com
2,Bob,bob@example.com

Tabs

Like list mode, but tab-separated - easier to paste into Excel or Numbers directly.

.mode tabs

1	Alice	alice@example.com
2	Bob	bob@example.com

HTML

Outputs table rows ready to drop into an HTML page.

.mode html

<tr><td>1</td><td>Alice</td><td>alice@example.com</td></tr>
<tr><td>2</td><td>Bob</td><td>bob@example.com</td></tr>

Insert

Generates runnable INSERT statements - good for producing quick migration or seed SQL.

.mode insert users

INSERT INTO users VALUES(1,'Alice','alice@example.com');
INSERT INTO users VALUES(2,'Bob','bob@example.com');

JSON

Use when you need to hand the results off to something that consumes JSON (note: some older JSON parsers error or warn on a top-level list).

.mode json

[
  {"id":1,"name":"Alice","email":"alice@example.com"},
  {"id":2,"name":"Bob","email":"bob@example.com"}
]

Markdown

Outputs a GitHub-flavoured markdown table, good for pasting into docs or READMEs.

.mode markdown

| id | name  | email               |
|----|-------|---------------------|
| 1  | Alice | alice@example.com   |
| 2  | Bob   | bob@example.com     |

Box

A nicer-looking version of table mode using Unicode box-drawing characters.

.mode box

┌────┬───────┬────────────────────┐
│ id │ name  │ email              │
├────┼───────┼────────────────────┤
│ 1  │ Alice │ alice@example.com  │
│ 2  │ Bob   │ bob@example.com    │
└────┴───────┴────────────────────┘

Quote

Similar to list mode but strings are single-quoted, matching SQL literal syntax.

.mode quote

1,'Alice','alice@example.com'
2,'Bob','bob@example.com'

ASCII

Uses ASCII control characters (unit separator 0x1F, record separator 0x1E) as delimiters - safe for data that might contain commas or pipes.

.mode ascii

1␟Alice␟alice@example.com␞
2␟Bob␟bob@example.com␞

Table

A plain ASCII bordered table, like box mode but without Unicode - useful in terminals that don’t support it.

.mode table

+----+-------+-------------------+
| id | name  | email             |
+----+-------+-------------------+
| 1  | Alice | alice@example.com |
| 2  | Bob   | bob@example.com   |
+----+-------+-------------------+

TCL

Outputs values as a TCL list - mainly useful if you’re scripting with TCL or tclsh.

.mode tcl

1 Alice alice@example.com
2 Bob bob@example.com

Demand for Software is Different

Rowan Marshall — Wed, 08 Jan 2025 00:00:00 +0000

Most things humans produce have a recognisable demand ceiling - the world will only eat so much bread, regardless of how cheap it is, and we’ll only upgrade our phones so often, no matter how nice the new models are.

If we get 10x times better at growing wheat, we don’t grow 10x more wheat, because we’re pretty close to that upper limit now - instead, we get 10x less wheat farmers, producing a similar quantity of wheat.

Software is a bit different.

Software doesn’t really have a recognisable demand ceiling. User interfaces can always be better, a server more performant, or more options added. There are whole industries left largely undigitalised and countless problems we haven’t even realised software can solve yet.

In a way, this is a retelling of Jevons Paradox: when a resource becomes cheaper or more efficient to produce, demand increases as we find new ways to use it at that lower price point.

Whenever we’ve made software development more efficient—whether through better programming languages, IDEs, libraries, frameworks, low-code tools, or AI—the result hasn’t been long-term unemployment for developers. Quite the opposite. We’ve seen more developers, paid even more, building bigger, faster, and more complex systems.

That’s why I’m bullish on AI programming tools and the future of software development jobs. Sure, the role will evolve, but software hasn’t finished eating the world yet. And until it does, there’s going to be high demand for people who specialise in solving problems with code.

Modifying a compiled executable

Rowan Marshall — Thu, 14 Feb 2019 00:00:00 +0000

Oh no!

Your boss, Harry, is leaving the company. He was a good guy and a good boss, who appreciated the simple things in life. One of those simple things was a little program called “who-the-boss” which, when run, printed out “Harry the boss!”.

His replacement is called Larry. Larry is a short-tempered man with little patience for anything he considers wrong, which is everything.

One day, he finds Harry’s program on a machine everyone forgot existed. He runs it, expecting it to say he, Larry, is the boss. When it prints out “Harry”, Larry is furious. He marches down past the espresso machine, fresh fruit and pool tables to the dev office and demand they change it now!. The thing is, no-one knows where the source code is for this program. You know your hexadecimals from your stack machines, so the team beg you to help.

First things first, you run the program to validate it’s output:

You open up Vim, making sure to use the :%!xxd command to open in hex mode.

Hmm, how to find Harry’s name… What’s the hex representation of Harry?

You quickly look up a table of UTF-8 character codes and find that “Harry” is “48 61 72 72 79” in hexadecimal UTF-8.

Right, lets search for that in Vim.

Right, we’ve isolated the “Harry” string. Now to change that H to an L.

There we are, done! Lets save that making sure to use the :%!xxd -r command to correctly switch back.

Perfect! Larry is content and the team owes you one.

Calling Nim from Python

Rowan Marshall — Sun, 27 Jan 2019 00:00:00 +0000

In this post I’ll show you how to write a function in Nim and call it in Python.

Nim

To start with we’ll need a Nim function. Here’s a one that takes 2 integers, adds them and returns the result:

called.nim

nim

proc nim_add(num1: int, num2: int): int {.exportc.} =
    return num1 + num2

Most of this is pretty ordinary, except for the {.exportc.} in the function signature. This is a pragma, which provides metadata about a function to the Nim compiler. Here, {.exportc.} mainly tells the compiler to keep the function name as it is in the .nim file instead of mangling it, so we know our function will still be called nim_add.

Now we need to compile this into a shared object to let Python call into it:

bash

nim compile --app:lib called.nim

This will create a shared object file called libcalled.so in your current directory.

Python

If you’ve used cffi before this will be very familiar.

calling.py

python


from cffi import FFI

ffi = FFI()

ffi.cdef("""
    int nim_add(int num1, int num2);
""")

lib = ffi.dlopen("./libcalled.so")
res = lib.nim_add(5, 10)
print(res)

Here we create an FFI object and load in the function definition of nim_add using the C function declaration syntax. There is an explanation on converting Nim types to C types in the Nim manual here. We then open our shared library from the current directory, and can call methods on the library object like any Python namespace.

Running it

Now we can just run the Python file like normal, and if the shared object file is in the expected place, cffi will call into it and we can add two numbers together, but in Nim!

bash

➜ python3 calling.py
15

Automatic memoization of function calls in Python

Rowan Marshall — Sat, 20 Jan 2018 00:00:00 +0000

The Fibonacci sequence is the integer sequence where each number is the sum of the previous two numbers, starting with zero and one:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34

Writing a function to calculate an arbitrary fibonacci number is a common problem in interviews and tests, that has an elegant if inefficient way of being solved via recursion.

Here’s a simple solution in Python:

python

def fib(n):
    if n < 2:
        return n
    else:
        return fib(n-1) + fib(n-2)

Given an integer n, this function will calculate the n’th number in the fibonacci sequence. If we try benchmarking this using the ever-useful timeout tool, using a value of 28:

bash

➜ python3 -m timeit -s 'import fib' 'fib.fib(28)'
2 loops, best of 5: 109 msec per loop

Reasonably fast. But if we up this to 30…

bash

➜ python3 -m timeit -s 'import fib' 'fib.fib(30)'
1 loop, best of 5: 291 msec per loop

A small increase almost tripled the algorithm’s runtime. If we increase this much more it will get exponentially slower to calculate, this being an O(2^n) algorithm. Why is this so inefficient?

To solve this, we need to look at how the function is being called. Here’s a diagram stolen from Stack Overflow showing the recursive tree of fib(n) calls being made:

25 seperate calls altogether, with 18 of those being repeats. The percentage of repeated calls gets much worse as n increases, meaning a lot of work is being done unnecessarily.

How can we fix this, without resorting to changing our algorithm?

Introducing the LRU Cache decorator

Inside the functools standard library package, there’s a decorator called @lru_cache. This decorator records the arguments a function is called with and the value the function returned. If that function is called twice with the same arguments, the lru_cache will return the same value it got the first time, saving us the overhead of calling it twice. Since our issue is repeated function calls, we should expect a significant speedup.

Lets try timing that again after adding the decorator:

python

from functools import lru_cache

@lru_cache
def fib(n):
    if n == 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fib(n-1) + fib(n-2)

bash

➜ python3 -m timeit -s 'import fib' 'fib.fib(30)'
2000000 loops, best of 5: 105 nsec per loop

That sped up our algorithm by about a million times. Not bad for one line of code.