The safety stage every rendered statement passes before it can run, on every path (saved
queries, composed queries, ad hoc SQL, TestQuerySQL, specs, data contexts).
It works from tokens, never from a complete parse, so a read query the structural parser cannot
fully read (T-SQL JOIN … JOIN … ON … ON, (NOLOCK)) still runs, and no parse failure can let a
write through:
one statement (no stacked statements), starting with SELECT or WITH;
every CTE a read, and the statement after the WITH clause a SELECT;
no top-level SELECT … INTO (it creates a table);
no call to a function the dialect lists in CallerSQLForbiddenFunctions (OPENROWSET,
pg_read_file, dblink, …): they read what a check of the referenced tables cannot see.
node-sql-parser plays no part. SQL with no statement at all (empty, only comments or semicolons)
runs nothing and passes, unless the caller asks for a statement (refuseEmpty, for SQL a caller
supplied).
The safety stage every rendered statement passes before it can run, on every path (saved queries, composed queries, ad hoc SQL, TestQuerySQL, specs, data contexts).
It works from tokens, never from a complete parse, so a read query the structural parser cannot fully read (T-SQL
JOIN … JOIN … ON … ON,(NOLOCK)) still runs, and no parse failure can let a write through:SELECTorWITH;SELECT;SELECT … INTO(it creates a table);CallerSQLForbiddenFunctions(OPENROWSET,pg_read_file,dblink, …): they read what a check of the referenced tables cannot see.node-sql-parser plays no part. SQL with no statement at all (empty, only comments or semicolons) runs nothing and passes, unless the caller asks for a statement (
refuseEmpty, for SQL a caller supplied).