Auto-magic string documentation

Trace an unexplained value through DDL and leave behind a useful note for the next person, possibly future you.

Found a mystery code in a result set? When SQLly can follow the value through DDL introspection, it leaves an inline note explaining where the value came from - so the query answers a little more of its own trivia.

SELECT status /* ← enum: orders.status_id → status_codes.code */

Where the explanation comes from

From the schema, in order of how much it can be trusted - and the note says which it used:

1. A foreign key. The value is an id into another table: follow it and name the referenced table and its readable column.
2. A check constraint. A column constrained to a handful of literals is an enumeration in all but name, and the constraint spells out the permitted set.
3. A lookup table. A small table of code-and-description rows joined by name rather than by a declared key - very common, and worth recognising.
4. An extended property or column comment, where your team already wrote the answer down and nothing has been showing it to you.

Documentation as a by-product

The pleasant part is the direction of travel: you were going to look this up anyway, and the note means the next person - quite possibly a future you - does not have to. It is the same instinct as Document Schema, applied one puzzling value at a time instead of a whole database at once.

Planned. The relationship and constraint model it needs already exists and already powers join suggestion and display-value resolution; this is a new surface over it rather than new knowledge.