Scott, Wefound a way, it was reallysimplethe solution was notunderstanding theuser management,had manymisconceptions(orbrought fromotherdatabaseenginesthatdrive). If anyone wouldbe neededas itgetssolved, I write.
Thank you very muchfor the prompt response,probably a goodsolution.Makes me thinkI'm not doingsomethingright, becauseSteveismyuserpostgres. I'm migratingsome 50databases thatwerespread over50 serverstoonecentral server. Each databasehas10GBon average. Each databasehas anowner user(in my exampleis theDBA)previouslyin the above schemeeachuser had thepostgrespasswordon each server. Sotorestore the databaseuseris the userpostgresSteveandBobneedto create a userthat istheaspostgresbut only inthat database. These users(programmers)usually makechanges to the database,createschemas, tables, views,etcand need tokeep doing thatinyour database. SoI gave themsuper-userpermissionsandaccesspg_hbarestingífromitsbase,yet they havemanyextrapermissionsthat are not desirableassuchcanonedeletethe databasethat is not theirs.
On Wed, Nov 28, 2012 at 11:58 AM, Gabriel Muñoz <gabriel.munoz@gmail.com> wrote: > As I can give you full permission to a user in a database. For everything > you have that database and the objects to be created in the future. > This means you can access all the schemes, all tables, views, functions, > etc. > If in the future you create a new view does not have to do a specific GRANT > to that user since the user is the "owner" of the database. > > Try saying the user is super-user and restrict access only to the database > from pg_hba. But being super-user can for example delete another database > that is not theirs.
If the db owner is steve, and you want bob to be able to do anything steve can do, you can do: