4 ms·

I'm sorry, I thought we were talking about security? Are you leaking the other thread into here just so you can feel like you won both, instead of neither? And

I'm sorry, I thought we were talking about security? Are you leaking the other thread into here just so you can feel like you won both, instead of neither? And I never said anything about any C/C++ type system doing anything? But okay. Back to the topic: if you've heard of them, why did you insist that SQL is inherently insecure? Did you forget they existed, or did you just think I wouldn't notice? Are you that cocky? I really hope your employer one day recognizes your incompetence and fires you, because the software world is plagued with enough bugs without people like you purposely and gladly laying out a red carpet for them to walk in on. I can't continue to argue with what is either a relentless geyser of misinformation or a brilliant troll, so I'm done. Maybe one day you'll come to your senses, but I doubt it.

innguest 11y ago
The way a strong type system solves this SQL injection problem (despite your saying it's impossible and ignoring my having shown your wrong) is by automatically escaping arguments before binding them to parameters. Well guess what, you don't need pre-compiled statements to benefit from this feature - all you need is the hoisting aspect of it. In other words, if SQL drivers did not offer the unsafe function exec_query that takes the whole query as a string and returns a result, and instead they only exposed a hoisted version of that function that takes a list of arguments and a placeholder query as a string... exec_query ["john", 12] "SELECT ... WHERE... = $1 AND ... = $2" Then there is no SQL injection problem, as the SQL database driver would always automatically escape the arguments before binding the parameters. So if only SQL database drivers did not offer exec_query but instead forced the user to provide the whole query string in one go with placeholders, then the driver would be able to enforce security at the proper software layer - which is not everyone's program that interacts with a database.

innguest 11y ago

The way a strong type system solves this SQL injection problem (despite your saying it's impossible and ignoring my having shown your wrong) is by automatically escaping arguments before binding them to parameters. Well guess what, you don't need pre-compiled statements to benefit from this feature - all you need is the hoisting aspect of it. In other words, if SQL drivers did not offer the unsafe function exec_query that takes the whole query as a string and returns a result, and instead they only exposed a hoisted version of that function that takes a list of arguments and a placeholder query as a string... exec_query ["john", 12] "SELECT ... WHERE... = $1 AND ... = $2" Then there is no SQL injection problem, as the SQL database driver would always automatically escape the arguments before binding the parameters. So if only SQL database drivers did not offer exec_query but instead forced the user to provide the whole query string in one go with placeholders, then the driver would be able to enforce security at the proper software layer - which is not everyone's program that interacts with a database.