A boolean column, a text column and a time column each need a way to record nothing, so what can serve each?

## The question is per column kind, not per table "Can this column hold a hole?" has no single answer for a table, because the answer depends on two things at once: **what the column's values are stored as**, and **which absence encoding the tool uses**. An encoding that lives inside the value can only work where the value format has a pattern to lend. An encoding that lives outside the value works everywhere. Walking three column kinds makes the rule concrete. ## A boolean column A boolean has exactly two states. Two storage choices are common: - **Packed, one bit per row.** Both patterns are taken. There is nothing spare, so an absence marker cannot live inside the value at all. - **One byte per row.** Most patterns are unused, so a tool *could* reserve one — but doing so means the column's values are no longer what a plain reader of a byte would assume, and the convention has to travel with the data. In practice, a boolean column that admits absence is a column with a validity track beside it or a typed absence marker the library defines. This is why some tools simply cannot store a hole in a boolean column: asked to, they turn it into a column of arbitrary references, and you have silently left the world of uniform typed storage. ## A text column Text is variable-length, so it is stored either as references to string objects, or as a values buffer with offsets into it. - Where the cells are **references to arbitrary objects**, the host language's own "nothing here" object — its empty reference — drops straight into the cell and the tool needs nothing else. The cost is that the column will accept anything: one loader leaves the language's empty reference, a numeric step leaves a reserved floating-point pattern, a third path leaves the tool's own marker, and the column now holds several different absence-ish objects. A check written for one of them under-reports the holes. - Where text is stored in its **own buffer with offsets**, absence is recorded beside the values in a validity track, exactly as for numbers, and the column stays uniform. ## A time column A time-typed column is almost always a whole number of ticks from an origin, dressed up with an interpretation. Under a design that reserves patterns inside values, that column needs an absence object of its own — **the absence marker a time-typed column uses, which is a different object from the numeric one** — because it must decode as a time, print as a time and order as a time. The practical consequence is a trap: - the general absence test recognises both, because it was written to; - code that tests for the *numeric* absence object by identity does not recognise the time one, and vice versa; - so a hand-rolled audit that counts holes with an equality against one marker reports a time column as complete when it is not. ## Summary of what serves what | column kind | pattern inside the value | validity bit beside it | the language's empty reference | the tool's typed marker | |---|---|---|---|---| | whole-number | no spare pattern | yes, width unchanged | only as a column of references | yes | | floating-point | yes, the format reserves one | yes | only as a column of references | yes | | boolean | not when packed | yes | only as a column of references | yes | | text | depends on the storage form | yes | yes, where cells are references | yes | | time | needs its own distinct object | yes | only as a column of references | yes | Read the table column-wise rather than row-wise and the rule falls out: **the two encodings that live outside the value serve every column kind, and the two that live inside the value are conditional on the format.** ## Why a column of arbitrary references is not the general answer It is tempting to treat "just make it a column of references" as the universal escape hatch, because it accepts every absence-ish object there is. Three things argue against it: 1. **The single-form guarantee is gone.** Every cell is a reference to anything, so nothing enforces that the column still contains one kind of thing, and nothing raises when it stops. 2. **Absence stops being one thing.** Several different absence-ish objects can coexist in the one column, so the number of holes depends on which check you ran. 3. **The declared representation stops carrying information.** Downstream code that reads the representation to decide how to handle the column learns nothing from it. The interview-grade summary is short: a tool that offers a marker outside the value — a validity track, or one typed absence marker — can admit absence in any column at that column's own width, while a tool that encodes absence inside the value must find a spare pattern per format and does not always have one.