The observations here apply to input from all of these sources (not interactive commands):
- stdin (pipe or redirect from a file)
.read command in the shell- CLI argument with the Turso shell
When a single statement is provided, the error message is helpful. For input select;, the error message is descriptive:
Error: failed to execute SQL: select;
SQL string could not be parsed: unexpected end of input at (1, 7)
However, when multiple statements are provided, the error message is not helpful. For input select; select:
Error: failed to execute SQL: select; select
Note that there are no diagnostics attached to the result.
The sqlite3 shell gives more usable output:
Parse error near line 1: near ";": syntax error
select; select
^--- error here
Also problematic is the fact that the entire input is printed in the error message. If you use a lengthy SQL script as input, and there is an error anywhere during its execution, the output contains the entire script contents as above, with nothing indicating the problem. This makes long scripts extremely difficult to debug.
The observations here apply to input from all of these sources (not interactive commands):
.readcommand in the shellWhen a single statement is provided, the error message is helpful. For input
select;, the error message is descriptive:However, when multiple statements are provided, the error message is not helpful. For input
select; select:Note that there are no diagnostics attached to the result.
The sqlite3 shell gives more usable output:
Also problematic is the fact that the entire input is printed in the error message. If you use a lengthy SQL script as input, and there is an error anywhere during its execution, the output contains the entire script contents as above, with nothing indicating the problem. This makes long scripts extremely difficult to debug.