I would say it kind of depends. It certainly written in bad form as you should almost never do direct variable insertion into your SQL query string. You should

I would say it kind of depends. It certainly written in bad form as you should almost never do direct variable insertion into your SQL query string. You should should be doing the variable substitution and a prepare execute type method. Either with your database doing it directly or with your libraries that are handling the queries to do it for you. If there is no possible way for an untrusted user to modify your userID, then there is no SQL injection possibility because that is a known set value from a piece of trusted code. If it's untrusted data there should also be additional sanitization around it before it even makes it this far to get concatenated into your query. Still all of that is a multi-layered approach to ensuring your data is properly sanitized. The final bit is proper query substitution. If I saw a piece of code like this it would immediately fail a PR review and anyone who argued that it's fine we would be engaging a wider engineering audience because that person needs a retrained. Additionally the select * is bad form as well. You should be returning the data that you need which is rarely an undefined all. Also for your union approach where it fails due to column mismatches you can address that by simply concatenating your columns together so you return the same number of expected columns in your injected query.