It's very unlikely that you could restrict the access to a single table in a real application, so you would have to specify all the required tables and maintain that list.
It's a somewhat normal approach to limit things to the database user on the larger scale, such as using different roles for reporting, normal users, admins etc. depending on which layers you're handling authorization and usually when you have multiple systems sharing the database (normal / reporting is a common use case). In many cases the actual database user is always the same, and the application will then (try to) make sure that no-one is doing anything they're not supposed to.
The architecture and security requirements determine where and how you should manage authorization. For example handling government data would mean you have multiple layers of authorization to prevent any intentional or accidental data access where not allowed.
Creating a temporary user would be complex, and it would give very little compared to creating well thought permanent user roles. Not to mention that to create temporary users you would need to have access to an admin role that can create users. It could be a potential security problem, since often applications don't require a superuser role for normal functionality.