Yeah, that's what's mapped in my head to "sanitizing input" in these cases, as it's the correct way to handle them. I should've unrolled my brain shortcut for the discussion.
Looking at the postgres JDBC source, it sanitizes parameters when prepared statements and parameterization is used. Different implementations may do different things here though
Cool - but neither of your comments addressed that I am still correct afaict, if you care about query plans and such parameterization is important, but not getting injected on is a different problem.
look, if you still want to live like it's 1999, then sure, go ahead and wrap your params in quotes like you think you can. just don't come crying to the rest of us that have more than once provided you with better solutions when you get attacked. i mean, even using the old style escape methods would be better than your appending of quotes idea.
I didn't say I don't use parameterization, and I still haven't heard what the difference is between the old style escape methods and the quotes I mentioned, just you being salty :)
Why use unreliable solutions that rely on various assumptions that may change in the future and rely on you not forgetting about even 1 case where it wouldnt work
When you can use approach which fundamentally prevents SQL injection?
"Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags."
But still this is not a way, input sanitization is bullshit.
Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query
is the correct solution since SQL injection is about affecting tree composition