@gogovan-vincentngai and Joaquín Fernández Campo, do we really need to define "object" privileges using the provider? As for my understanding, the provider could help us define the database and its owner (and schemas is a nice to have); From this point on, projects will rely on db management tools like liquibase as soon as you give them a database owner.
Idk if you agree with me on this point? What would be the use case where the provider should also manage privileges on tables?

@gogovan-vincentngai and Joaquín Fernández Campo, do we really need to define "object" privileges using the provider? As for my understanding, the provider could help us define the database and its owner (and schemas is a nice to have); From this point on, projects will rely on db management tools like liquibase as soon as you give them a database owner. Idk if you agree with me on this point? What would be the use case where the provider should also manage privileges on tables?

I think we do need this, the use case i currently need this for is the following:

"One team manages and provisions database users with some default roles, the application teams get access to a role for migrations and another role for application usage. The application role is the one that needs default permissions for the resources created by the migration user. There's others roles in the system that also require this default privilege system setup"

This same problem could be solved using a different approach (the one you mentioned), but in general it's a pattern we want so we don't have to make the applications aware of other roles like, for example, an analytics role.

The other argument for this is that default privileges (here) is not really related to specific table grants, i think having a way of crafting a policy about roles is good (role A can access all tables created by role B from now on)