Function sql_is_effectively_blank 

pub fn sql_is_effectively_blank(input: &str) -> bool

True when input carries no SQL statement for the engine to run: it is empty, whitespace, or nothing but comments.

The CLI needs this to decide whether a --exec / --exec-file segment is skippable, and it cannot reuse the PowQL blank check for SQL. PowQL’s comment introducer is #; SQL’s is --, which the PowQL lexer reads as two subtractions. So a dump ending in -- end of dump looked like a real statement, reached the engine, and failed with expected SQL statement, got <eof> after every real statement had already committed, which aborts a set -e deploy script that had in fact succeeded.

This asks the real SQL lexer rather than scanning for --, so the answer cannot drift from the dialect: -- inside a string literal is not a comment, and /* ... */ blocks are handled for free. lex_sql itself stays private because its token type is an implementation detail; this predicate is the minimum public surface that answers the CLI’s question.

A lex error is deliberately not blank: that input is a real statement with a real problem, and the engine should be the one to report it. The single exception is a # comment. # is not SQL’s comment character (see docs/SQL.md), so lex_sql rejects it outright, but the CLI shares one REPL across both dialects and has always skipped #-only lines. Flipping those to exit 1 purely because the session is in SQL mode would be a regression, so they are stripped and re-offered to the same lexer.