Tom Lane wrote:
The hole in your argument is that this is not so. The purpose of a
backup is to get the *user's* objects into the same state they were
in. If we applied that reasoning to *system* objects then presumably
loading a dump from an 8.2 database into 8.3 would magically destroy
all th
I got a broader view of the whole picture and obviously my proposal
that the superuser automatically revokes the privileges granted by all
others does not make sense. So let me state the solutions I propose to
the problem I'm facing:
(1) In the documentation for REVOKE, after the paragraph
On 05/30/2007 08:44:19 PM, Pedro Gimeno Fortea wrote:
Note that this is not similar to the GRANT case. I'd say it's similar
to wanting to delete a table created by another user: if you're not
the owner, you can't, unless you're a superuser. The similarity
becom
On 05/30/2007 07:55:58 PM, Tom Lane wrote:
Pedro Gimeno Fortea <[EMAIL PROTECTED]> writes:
> Still, is silently ignoring the command the proper action to take
> when the REVOKE is executed by the superuser and not by the
> grantor?
You want a warning when REVOKE didn't
On 05/30/2007 06:57:39 PM, Tom Lane wrote:
Pedro Gimeno Fortea <[EMAIL PROTECTED]> writes:
> On 05/29/2007 03:35:00 PM, Tom Lane wrote:
>> This is not a bug. If you want to revoke the privilege, revoke
>> the GRANT OPTION you originally gave.
> Why should I?
Because
On 05/29/2007 03:35:00 PM, Tom Lane wrote:
"Pedro Gimeno" <[EMAIL PROTECTED]> writes:
> When a USAGE grant on a SCHEMA is given by an user (non-superuser
> in my case), the superuser can't revoke it; instead the REVOKE
> statement is silently ignored.
This is not a bug. If you want to revoke t
