This doesn't actually work. It is possible to produce objects with 'static lifetime references at runtime.<p>What &'static means is that whatever the reference is pointing at will never be modified or go out of scope. One way to provide this is to put it in the read-only part of the executable, which is what literals do. Another is to use into_boxed_str() [1] and Box::leak() [2] to leak the string and thus make sure it will never be modified or freed. Neither function is unsafe, while Box::leak() is still only in nightly.<p>[1]: <a href="https://doc.rust-lang.org/std/string/struct.String.html#method.into_boxed_str" rel="nofollow">https://doc.rust-lang.org/std/string/struct.String.html#meth...</a>
[2]: <a href="https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak" rel="nofollow">https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...</a>
This is a pretty natural thing to want, but is not actually usable in real world settings.<p>If your SQL has to be computed at compile time, how do you implement any sort of search where you will have a variable number of ANDS & ORs?
I think the main problem (don't know whether this is possible in Rust which I am not familiar with) is that untrusted input is passed around as strings at all (Java, which I am familiar with, does this). I'd prefer:<p>- Getting untrusted input as a separate type<p>- Having only a controlled way to put instances of this type into an SQL query
It's a neat little hack, though it seems a bit restrictive. I was expecting a blog post about how, by using ownership, it should be possible to create an API that both requires untrusted data to be escaped and prevents double-escaping (though you could probably achieve pretty much the same in any statically-typed language).
Is this serious? It seems to prevent SQL injection by only allowing statically defined strings to be interpolated. So basically not allowing any kind of dynamic or user input.