From: | Lou Duchez <lou(at)paprikash(dot)com> |
---|---|
To: | Erik Jones <erik(at)myemma(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: requests / suggestions to help with backups |
Date: | 2007-02-16 15:49:50 |
Message-ID: | 20070216154950.GA22291@ds214-170.ipowerweb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> >Certainly, I've
> >tried "grant select on database mydatabase to user myuser"; it doesn't
> >work, because "select" is not a database-level privilege.
> Sorry, you're right on that one. I misread it. However, it shouldn't
> be too hard to write a script, either in a procedural language or higher
> level, to pull the existing table names from pg_class and invokes the
> GRANT command for you "trusted" user on each.
That could be done, but my big worry is all the non-table components of
a database such as views and functions -- I'd hate to accidentally be
creating incomplete dumps simply because I forgot to programmatically
assign permissions on my operator classes (or whatever).
So I'd still like to see a "read" or "readonly" permission at the database
level, but until then, it seems the best bet is to use an overprivileged
trusted account for my backups. The security risks can be managed, and
they are worth it to make sure I've got a complete and cohesive dump.
From | Date | Subject | |
---|---|---|---|
Next Message | Rafael Comino Mateos | 2007-02-16 17:19:56 | What about TSearch2 |
Previous Message | Erik Jones | 2007-02-16 15:30:21 | Re: requests / suggestions to help with backups |