Well, not really. Not in the way OP is describing. Of course queries are literally compiled at run time. But by then it's too late as user-supplied data is alre

Well, not really. Not in the way OP is describing. Of course queries are literally compiled at run time. But by then it's too late as user-supplied data is already in the payload that is being compiled. Even stored procs don't protect you as their invocation itself is a runtime sql which can fall victim to injection. To achieve what OP wants would require a "build time" compilation. And a permission system where a SQL-account is restricted to only run/execute these pre-built queries and commands. No ad-hoc sql allowed at runtime. Stored procs only get you half-way there, ignoring their own invocation is a runtime sql vulnerable to injection. As of today, good coding practice with parametrized queries and procedure invocation is your only protection. But your app may not "own" the DB. Just a cog in a larger system. What OP is suggesting would move the shield closer to the data for better protection. So the 20+ other apps out of your control don't mess things up.