Timeline for Why did SQL injection prevention mechanism evolve into the direction of using parameterized queries?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 24, 2016 at 11:00 | comment | added | Wildcard | @Eric, that's frankly horrifying. (I use Postgres; if it has any such bizarre warts I've yet to encounter them.) | |
| Sep 17, 2016 at 6:07 | comment | added | Eric | @TomTom Encoding is actually very hard to get right once you factor in time. What do you do when your DB vendor decides to create a new comment style in the next release or when a bareword becomes a new keyword in an upgrade? You could theoretically get encoding actually right for one release of your RDBMS and be wrong on the next revision. Don't even get started on what happens when you switch vendors to one that has conditional comments using nonstandard syntax | |
| Sep 15, 2016 at 8:53 | comment | added | James_pic | Perhaps SQL Server is sufficiently regular that it's a non-problem, but I've encountered problems in other DBs - corner cases with mismatched character encodings, obscure config options, locale specific date and number issues. All solvable, but needing at least a cursory understanding on the DB's quirks (I'm looking at you, MySQL and Oracle). | |
| Sep 14, 2016 at 17:47 | comment | added | TomTom | "Encoding is hard to do right" - hahaha. It is not. A day or two, it is all documented. I wrote an encoder many years ago for an ORM (because sql server has a limit on parameters and thus it is problematic to insert 5000-10000 rows in one statement (back 15 years ago). I do not remember that being a large problem. | |
| Sep 14, 2016 at 16:28 | history | edited | James_pic | CC BY-SA 3.0 | added 210 characters in body |
| Sep 14, 2016 at 16:15 | history | edited | James_pic | CC BY-SA 3.0 | added 51 characters in body |
| Sep 14, 2016 at 16:08 | history | answered | James_pic | CC BY-SA 3.0 |