> Using proposed by Richard workaround<br> > **sqlite> .param set @vvv "'+1+2+3'"**<br> sorry, but is not intuitively > understandable why to do it, especially if this shell's behavior isn't documented. It is, in fact, [documented](https://sqlite.org/cli.html#rules_for_dot_commands_): > Text bounded by a pair of single-quotes or double-quotes is treated as a single argument, with the quotes stripped. Within a double-quoted argument, traditional C-string literal, backslash escape sequence translation is done. That is pretty clear to me, though admittedly, C-style quoting may not be for the faint of heart. As they say, the difference between a bug and a feature is whether it is documented or not. (I don't totally agree, but there is some truth to it.) Look, I get it: Escape conventions are indeed very tricky, and we all fall victim to their various traps from time to time. It would be very nice indeed they could be avoided. To that end, it would be very nice indeed if there were a way to avoid it. One way might be to add a third way of quoting to dot-commands: For example, if white space is followed by a `#` character, the rest of the intput line would be taken verbatim as the final argument (choice of trigger character subject to debate, of course). Another way would be to introduce special quoting rules for `.param`, but that ruins consistency, and is better avoided, I think. > The whole point of .dot command **.param** is to emulate prepared statement to be make sure value will be passed to database engine **as is**, without modifications and what is **most important** - without trying to evaluate content(!!!). Hmm, I thought it was just a convenient way to store a value that you might want to use repeatedly. Or, to let you easily rerun a complex query with different values, by changing the parameter and rerunning the exact same query. Your proposed rationale does not make a lot of sense to me.