codenotary / immudb / 30524793846

85%

Build Type

push

gh-ci

Committed by vchaindz

Commit Message

chore(sql): treat nil row-value slots as SQL NULL in remaining consumers

The projection-pushdown optimization leaves Row.ValuesByPosition[i]
nil for columns a query does not reference. A repo-wide audit after
the fileSorter.encodeRow panic (#2100) found five more consumers that
dereference every positional slot and stay safe only because
projection currently repopulates rows before they run:

- CTE materialization (materializeCTE/materializeRecursiveCTE)
  type-asserted v.(ValueExp) on each slot: hard panic on a nil
  interface. Extracted rowValuesToValueExps, which substitutes a
  typed SQL NULL.
- Row.digest (DISTINCT, diff) called v.Type() on every slot; nil now
  digests the same as NULL.
- setOpRowReader.rowDigest (EXCEPT/INTERSECT) called v.IsNull(); nil
  now digests the same as NULL.
- sqlRowsToProto (gRPC row serialization) dereferenced every slot;
  nil now serializes as SQL NULL.
- embedded/document readers dereferenced positions 0/1 unchecked; nil
  or missing slots now return ErrUnexpectedValue.

None of these is reachable today: every external Resolve passes nil
scanSpecs and SelectStmt.Resolve always projects before returning.
The guards remove the reliance on the "projection always runs first"
invariant, which has already broken once. Unit tests encode the
nil-slot-equals-NULL contract.

The same audit confirmed the empty-statement-slice class from #2100 is
fully closed: every ParseSQL/ParseSQLString call site is now length-
guarded, range-based, or parses hardcoded non-empty input.

Coverage Stats

39 of 57 new or added lines in 6 files covered. (68.42%)

70 existing lines in 5 files now uncovered.

45268 of 53278 relevant lines covered (84.97%)

126070.99 hits per line