Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> nothing happens, because the revoke is implicitly assumed to mean
>> "revoke whatever privileges I granted", and Larry's superuser hasn't
>> granted any. The public privileges on language SQL were granted by
>> user postgres, and t
Tom Lane writes:
> nothing happens, because the revoke is implicitly assumed to mean
> "revoke whatever privileges I granted", and Larry's superuser hasn't
> granted any. The public privileges on language SQL were granted by
> user postgres, and they remain in force. So the later CREATE FUNCTION
Okay, the cause of the permissions regression failure is this:
Larry is running the regression tests as a superuser, but not as the
original postgres superuser. This means that when the privileges
regression test does
REVOKE ALL PRIVILEGES ON LANGUAGE sql FROM PUBLIC;
nothing happens, b
--On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
[snip]
Is this a bug, or is it correct-per-spec behavior? It's surely likely
to confuse people. I wonder whether superusers shouldn't be allowed to
revoke privileges granted by other people. As the code stands
--On Wednesday, October 29, 2003 15:49:53 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
--On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20
<[EMAIL PROTECTED]> wrote:
[snip]
Is this a bug, or is it correct-per-spec behavior? It's surely likely
to
Larry Rosenman <[EMAIL PROTECTED]> writes:
> --On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20
> <[EMAIL PROTECTED]> wrote:
> [snip]
>> Is this a bug, or is it correct-per-spec behavior? It's surely likely
>> to confuse people. I wonder whether superusers shouldn't be allowed to
>> revo
