According to this question, SQL injection is something one would have to prevent. In an application where the user is only selecting from the database, how would this be a concern?
Here are some examples of problems that SQL injection could allow even if the user is restricted to SELECT privilege:
The attacker could read data intended to be read only by other users. Many applications use the same MySQL user to connect, and then enforce further data-access restrictions with application code. I.e. I'm only supposed to see the shopping cart that I created. But with SQL injection, I could read everyone's shopping cart, their purchase history, their credit card number, and so on.
The attacker could read the hashed passwords of other accounts, crack them (on his own computer), and then log in to another user with greater privileges.
The attacker could run a denial-of-service attack by running a SELECT query that uses too many resources. For example, on MySQL, the table INFORMATION_SCHEMA.CHARACTER_SETS is readable even for a user with no privileges. Now what is going to happen when the attacker runs this query:
SELECT * FROM (SELECT * FROM CHARACTER_SETS, CHARACTER_SETS, CHARACTER_SETS,
CHARACTER_SETS, CHARACTER_SETS, CHARACTER_SETS) AS t ORDER BY 1
It tries to create a temp table on disk for 2,839,760,855,281 rows. I predict that will exhaust disk space on your server.
Your question sounds like you're fishing for a rationale for skipping writing safe code that protects against SQL injection.
Sorry, no dice. You need to write safe code.