Jeg vil først besvare dit "side-quest"-spørgsmål:
du har fuldstændig ret med dine bekymringer og bekymringer, og alle, der designer en applikation, bør tænke på de samme ting. Alt andet er sjusket og skødesløst.
For at afbøde den skade, der kan forårsages af et vellykket SQL-injektionsangreb, bør du helt sikkert anvende princippet om mindste privilegium.
Det burde være ganske enkelt at sætte et system op, der matcher dine krav.
Jeg bruger objektnavnene fra dit eksempel, bortset fra at jeg bruger understregninger i stedet for minusser. Det er en god praksis kun at bruge små bogstaver, understregninger og tal i objektnavne, da det vil gøre dit liv lettere.
/* create the database */
\c postgres postgres
CREATE DATABASE test_database WITH OWNER app_admin;
\c test_database postgres
/* drop public schema; other, less invasive option is to
REVOKE ALL ON SCHEMA public FROM PUBLIC */
DROP SCHEMA public;
/* create an application schema */
CREATE SCHEMA app AUTHORIZATION app_admin;
/* further operations won't need superuser access */
\c test_database app_admin
/* allow app_user to access, but not create objects in the schema */
GRANT USAGE ON SCHEMA app TO app_user;
/* PUBLIC should not be allowed to execute functions created by app_admin */
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin
REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
/* assuming that app_user should be allowed to do anything
with data in all tables in that schema, allow access for all
objects that app_admin will create there */
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
GRANT SELECT, USAGE ON SEQUENCES TO app_user;
ALTER DEFAULT PRIVILEGES FOR ROLE app_admin IN SCHEMA app
GRANT EXECUTE ON FUNCTIONS TO app_user;
Men tager man princippet om mindst alvorligt, bør man give bordtilladelser individuelt og f.eks. tillad ikke app_user til DELETE og UPDATE data i tabeller, hvor det ikke er nødvendigt for brugeren at gøre det.