Denial of service
An attacker could construct a query condition that's very resource intensive, and run it repeatedly, making the server so overloaded that it can't serve normal requests.
For starters, even if there are no other options to see the results through your app, an attacker probably can construct a timing-based channel for information extraction. I won't provide specific examples as they're time consuming, but it's reasonable to expect that this would be possible. The original question notes that there's no confidential information in the database, but there's probably some confidential information outside the database obtainable by methods described below.
Escaping your sanitization
Again, I won't construct a specific example, but "no strings with ;, /* or -- are allowed." is generally not sufficient sanitization, so I'll assume that there's a way for the attacker to execute multiple arbitrary SQL commands in this scenario. And this is a bit of a moving target - if someone provides you a counterexample using a UNION subquery or some unicode handling weirdness that allows bypassing the filters and you fix that, you'll still have more holes in it.
Read arbitrary files
select pg_read_file('/etc/passwd', 0, 10000) will return contents of a file on the database server - a penetration test would likely show that there's some convoluted way to extract that data.
Write arbitrary files
If arbitrary SQL can be executed, an attacker might run something like
COPY mytable (mycol) TO '/var/www/test.php' which in some cases (depending on the system user under which postgresql is running) can allow further exploitation
Execute system commands
Again, if your sanitization can be somehow broken and arbitrary SQL can be executed, then commands like
DROP TABLE IF EXISTS myoutput;
CREATE TABLE myoutput(filename text);
COPY myoutput FROM PROGRAM 'ps aux';
SELECT * FROM myoutput ORDER BY filename ASC;
(with some obfuscation to avoid naive filtering) would allow an attacker to execute arbitrary system commands on the server.