In an ideal world, I'd agree. But in the real world we live in, this has a huge cost: Legacy code, tools built around SQL, enourmous amounts of real life applications handling tons of data every day.
All (serious) SQL-tutorials, books and classes DO discourage string concatenation as a way of building queries. It can be parameterized as it is today, so the problem IS solved. People are just not using the solution, sadly.
I'd rather see an evolutionary move against what you're saying with the existing SQL of today; not a complete deprecation and rewrite/recreation. If we're at the complete recreation point, this could be done to so many things - and it's often similar reasons for it not to be done (existing systems and code bases).
Yeah, agreed. I think the main takeaway is to never build a platform where the easiest or default way of doing things is insecure. Depreciation can be impossible.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In an ideal world, I'd agree. But in the real world we live in, this has a huge cost: Legacy code, tools built around SQL, enourmous amounts of real life applications handling tons of data every day.
All (serious) SQL-tutorials, books and classes DO discourage string concatenation as a way of building queries. It can be parameterized as it is today, so the problem IS solved. People are just not using the solution, sadly.
I'd rather see an evolutionary move against what you're saying with the existing SQL of today; not a complete deprecation and rewrite/recreation. If we're at the complete recreation point, this could be done to so many things - and it's often similar reasons for it not to be done (existing systems and code bases).
Yeah, agreed. I think the main takeaway is to never build a platform where the easiest or default way of doing things is insecure. Depreciation can be impossible.