Skip to main content

execute_sql

Function execute_sql 

Source
pub fn execute_sql(
    db: &Arc<Db>,
    sql: &str,
    read_only: bool,
) -> Result<Executed, String>
Expand description

Run ONE statement. Err carries an already-encoded ErrorResponse.

Every SQL→NEDB decision lives here, which is the point: the extended query protocol added below is then purely a matter of message framing, and cannot drift from the simple path’s semantics. Run one neQL statement against a database, in process.

§Why this exists

Until this, the engine had exactly one SQL execution path and it was welded to the wire protocol: execute_stmt is private, takes the connection’s read-only flag, and reports failure as ALREADY-ENCODED Postgres error bytes. Nothing outside a pgwire session could run SQL against a Db.

That was survivable while the only SQL client was a socket. It stopped being survivable when neSQL — which owns the language — needed to run the language from a CLI, because the alternatives were a CLI that opens a TCP connection to its own process, or a second SQL front end living in the CLI. The second one is worse than it sounds: it makes the CLI a quieter second authority on what the language accepts, and the first divergence between them would be discovered by a user, not by us.

So the path the wire already takes is exposed, with the error decoded into text. Same parser, same translator, same evaluator, same decision about which engine runs a statement — one authority.