Summary
Referencing a column that does not exist never fails. Depending on where the name
appears, the query returns nulls, returns nothing, or ignores the clause — but it
always exits 0. Unknown table names are rejected properly, so the strictness is
there for tables and missing for columns.
Since the documents / blocks schema isn't something a user can introspect
before writing a query, a misremembered column name is the most likely mistake to
make against this database, and it's currently the one with the quietest failure.
Reproduction
mkdir -p /tmp/mqbug/docs && cd /tmp/mqbug
printf '# Alpha\n\nIntro paragraph.\n\n## Install\n\nRun the installer.\n' > docs/a.md
printf '# Beta\n\nAnother paragraph.\n\n## Usage\n\nUse it well.\n' > docs/b.md
mq-db index docs -o s.mq-db
In SELECT — column appears, filled with null
$ mq-db sql -d s.mq-db -F json "SELECT path, no_such_column FROM documents"
[{"path":"docs/b.md","no_such_column":null},{"path":"docs/a.md","no_such_column":null}]
In WHERE — predicate silently matches nothing
$ mq-db sql -d s.mq-db -F json "SELECT path FROM documents WHERE no_such_column = 'x'"
[]
This is the damaging one. [] is indistinguishable from a correct empty result,
so a typo reads as "no documents match" — a plausible answer a caller will
believe.
In ORDER BY — clause silently ignored
$ mq-db sql -d s.mq-db -F json "SELECT path FROM documents ORDER BY no_such_column"
[{"path":"docs/b.md"},{"path":"docs/a.md"}]
Control: unknown tables are rejected
$ mq-db sql -d s.mq-db "SELECT * FROM no_such_table"
Error: SQL execution error: unknown table: no_such_table
Expected
An error naming the unresolvable column, in all three positions — matching the
existing unknown-table behavior. Something like:
Error: SQL execution error: unknown column: no_such_column
A "did you mean" suggestion would be a nice touch, since mq already does this
(no function, selector, or module named 'nodes' — did you mean 'nones'?), but
the plain error is the part that matters.
Environment
mq-db 0.2.1, installed via cargo install
- macOS 26.6.2 (build 25G83), arm64
Summary
Referencing a column that does not exist never fails. Depending on where the name
appears, the query returns nulls, returns nothing, or ignores the clause — but it
always exits 0. Unknown table names are rejected properly, so the strictness is
there for tables and missing for columns.
Since the
documents/blocksschema isn't something a user can introspectbefore writing a query, a misremembered column name is the most likely mistake to
make against this database, and it's currently the one with the quietest failure.
Reproduction
In
SELECT— column appears, filled withnullIn
WHERE— predicate silently matches nothingThis is the damaging one.
[]is indistinguishable from a correct empty result,so a typo reads as "no documents match" — a plausible answer a caller will
believe.
In
ORDER BY— clause silently ignoredControl: unknown tables are rejected
Expected
An error naming the unresolvable column, in all three positions — matching the
existing unknown-table behavior. Something like:
A "did you mean" suggestion would be a nice touch, since
mqalready does this(
no function, selector, or module named 'nodes' — did you mean 'nones'?), butthe plain error is the part that matters.
Environment
mq-db 0.2.1, installed viacargo install