Gert Corthout <gert_corth...@hotmail.com> wrote: > My argument so far is that parametrized queries are way faster if used > properly. > The next obvious argument is sql injection. On all string input a simple > conversion is done: any ' is replaced by '', that's it. > This seems to block off any sql injection right there as the escape character > \ doesn't work in sqlite.
Yes, this should be sufficient to prevent the attack. %q specifier in sqlite3_mprintf performs the same manipulation, for the same reasons: http://www.sqlite.org/c3ref/mprintf.html > Alternatively can I make sql statements fail by including funky characters or > character combinations? It would be difficult to get SQLite to crash outright. It would take any sequence of bytes and stuff it into the database as-is. That said, you might get strange results with strings that are not well-formed UTF-8 or UTF-16 sequences (depending on which API flavor you are using). However, this is equally true for strings bound as parameters as well as string literals embedded directly into the statement. Performance is really the strongest argument. sqlite3_prepare is a fairly expensive operation, it's beneficial to run it once and reuse the statement many times with different parameters. Plus the time you save on not having to pre-process the strings, plus the peace of mind knowing that you haven't accidentally missed a spot where such pre-processing would be necessary. -- Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
