Yes, there's nothing magical about it...once you've figured out the quoting rules of *both* the shell *and* SQLite.
Take the last string I mentioned, for instance:
```
$ sqlite3
SQLite version 3.35.5 2021-04-19 18:32:05
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .mode column
sqlite> .param set :quote "\"I'm full\", said Bob."
sqlite> select * from sqlite_parameters;
key value
------ ---------------------
:quote "I'm full", said Bob.
```
Right off the bat, it's an exception to the "single-quote for strings (double up single quotes internally), double-quote for identifiers" rule of thumb that's been SQL lore since forever.
Setting that aside, it looks like this on the command line:
```
$ sqlite3 -cmd ".param set :quote \"\\\"I'm full\\\", said Bob.\"" :memory 'select * from sqlite_parameters'
```
which isn't entirely unmanageable, but then hard-coded parameters aren't all that useful. It's much more likely that the value comes from user input, or from a file:
```
$ read quote
# user types: "I'm full", said Bob.
# This absolutely will not work, but only experienced shell folks will know why...and how to fix it.
$ sqlite3 -cmd ".param set :quote \"${quote}\"" :memory 'select * from sqlite_parameters'
```
`sqlite3_bind()`, and similar facilities in almost every SQL language binding, largely remove the need to deal with SQL quoting issues. The fact that `sqlite3` has parameter substitution facilities, but forces both string substitution and SQL parsing to populate them, seems like an "impedance mismatch" to me:
```
$ read quote
# user types: "I'm full", said Bob.
$ sqlite3 -param :quote "$quote" :memory: 'select * from sqlite_parameters'
# No muss, no fuss, no errors.
```
Two questions:
1. Am I missing something here?
2. If not, any objections to a patch to enable the above facility?