Hello Scott, thanks for your answer. I've just noticed that my first message lacked some important info.
First, this is an accounting software, and there's only one database. Almost all of the options (buttons, generally ) are stored in a set of tables, beside the database privileges needed to work properly. Permissions are assigned from the application, and they're translated internally as a list of grant/revoke commands on tables, sequences, functions and schemas. Every application user is a pgsql role with login and nosuperuser options.
Right now there are about 20 users, 3 of them with admin permissions (still regular users, but they can execute functions and modify data that others can't). They can't create, alter or drop database objects.
Doing backups will be just an option more to enable/disable and it's not likely to be a public one, just a few people will be allowed to do it. What they do with the backup file is beyond my scope, of course, but I wouldn't like to see a bunch of users having fun with the database server ;) . This is why I'm thinking of a temporary superuser privilege, or even a temporary read access to let a user execute pg_dump and pg_dumpall without being a superuser. By the way, I don't like the idea of backing up the postgres account, I might need to create a customized dump to include just the regular roles and their md5-passwords.
Maybe, as said by a scottish girl: I think I'm paranoid...