Before we get to nuts and bolts here, please understand that I'm looking for insight here and hoping to get your request reduced to its vital essence. > It would be very useful for those who using sqlite3 CLI program as a mechanism/frontend/TUI to access databases. This is how the dev team sees the sqlite3 shell also, with limitations that may be relaxed over time. > As of now users of sqlite3 CLI/shell should take care about supplied data from external resources and be responsible for data sanitation to prevent SQL injection. I find this difficult to understand. (I understand SQL injection, just not the hazard in this context.) If I am able to type at or prepare input for the shell, I need not bother with any tricky "SQL injection" because I can simply write the SQL I want executed and cause it to be run. Hence, I need to understand an actual hazard scenario that is alleviated by your suggestion. > Current .dot command ".parameter set" is not true key/value binding feature that can be used as a mechanism to prevent SQL injection, that's why I suggesting to implement new .dot command. Before getting to <b>how</b> to avoid SQL injection, let's get to <b>why</b>. > Proposal is to implement new .dot command .parameter bind KEY VALUE , where VALUE can be anything, including un-escaped quotes, so it can be safely used later in prepared statements. For purposes of this discussion, until that <b>why</b> is understood, I am translating "safely" to "conveniently". > To avoid "escaping hell" with supplied VALUE, I suggest to accept VALUE as raw bytes content on the right side of command, after first space that follows KEY and up to the end of line or up to first 0x00 byte. I'm translating "avoid 'escaping hell'" to "make convenient". (I have no personal hope of avoiding "escaping Perdition". It goes with the territory.) Your proposal means breaking the interface between the shell's parser and the meta-command implementations. That is a very big step, and overkill for the problem at hand, in my (present) opinion. An alternative would be to join, with spaces, all arguments past the KEY. If somebody wants <i>more</i> spaces, they can endure some quoting work. > If it going to be implemented, it will be also very useful, if **`VALUE`** in the proposed .dot command will support **`.read`** command, that can be distinct from proposed one as:<br> <b>.parameter bindfile KEY FILE</b><br> or<br> <b>.parameter bindblob KEY FILE</b><br> by utilizing existing code of <b>.read</b> command. I believe that the existing ".param set KEY VALUE" can be made to set a blob value in the temp.sqlite_parameters by using the readfile() function. How does this proposal differ in effect from doing that?