On Tue, Mar 26, 2024 at 5:22 AM Étienne BERSAC
wrote:
> > ldap2pg really ought to issue REVOKE x FROM y GRANTED BY z.
>
> Thanks for this. I missed this notation and it is exactly what I need.
>
> You could consider this subject as closed. Thanks for your time and
> explanation.
No problem. Glad
Hi,
> ldap2pg really ought to issue REVOKE x FROM y GRANTED BY z.
Thanks for this. I missed this notation and it is exactly what I need.
You could consider this subject as closed. Thanks for your time and
explanation.
Regards,
Étienne
On Wed, Mar 20, 2024 at 1:26 PM Étienne BERSAC
wrote:
> The usual case is: a superuser grants writers role to alice. In
> directory, alice is degraded to readers. ldap2pg is not superuser but
> has CREATEROLE. ldap2pg applies the changes. In Postgres 15, revocation
> is completed. In Postgres 16,
Hi,
> https://dev.mysql.com/doc/refman/8.0/en/revoke.html documents an "IF
> EXISTS" option whose documentation reads, in relevant part,
> "Otherwise, REVOKE executes normally; if the user does not exist, the
> statement raises an error."
>
> https://community.snowflake.com/s/article/Access-Con
On 18.03.24 22:30, Tom Lane wrote:
regression=# revoke foo from joe;
WARNING: role "joe" has not been granted membership in role "foo" by role
"postgres"
REVOKE ROLE
What the OP is on about is that that last case issues WARNING not
ERROR.
Another point is that granting a role that has alread
Robert Haas writes:
> On Sat, Mar 16, 2024 at 8:17 PM Tom Lane wrote:
>> Even taking the position that this is an unspecified point that we
>> could implement how we like, I don't think there's a sufficient
>> argument for changing behavior that's stood for a couple of decades.
> I got curious a
On Sat, Mar 16, 2024 at 8:17 PM Tom Lane wrote:
> Even taking the position that this is an unspecified point that we
> could implement how we like, I don't think there's a sufficient
> argument for changing behavior that's stood for a couple of decades.
> (The spelling of the message has changed o
Hi Tom,
Thanks for your anwser.
> It does not say that that set must be nonempty. Admittedly it's not
> very clear from this one point. However, if you look around in the
> standard it seems clear that they expect no-op revokes to be no-ops
> not errors.
Postgres actually identifies memberhip
=?ISO-8859-1?Q?=C9tienne?= BERSAC writes:
> I'll try to patch the behaviour to ensure an error if the REVOKE is
> ineffective.
I think we're unlikely to accept such a patch. By my reading, the way
we do it now is required by the SQL standard. The standard doesn't
seem to say that in so many wor
Hi David,
> That should have read: the granted permission does not exist
Thanks, its clear.
However, I'm hitting the warning when removing a role from a group. But
the membership remains after the warning. In this case, I expect an
error.
I'll try to patch the behaviour to ensure an error if t
On Sat, Mar 16, 2024 at 1:00 PM Étienne BERSAC
wrote:
>
> > The choice of warning is made because after the command ends the
> > grantmin question does not exist. The revoke was a no-op and the
> > final state is as the user intended.
>
>
> Sorry, can you explain me what's the grantmin question
Hi David,
Thanks for your answer.
> The choice of warning is made because after the command ends the
> grantmin question does not exist. The revoke was a no-op and the
> final state is as the user intended.
Sorry, can you explain me what's the grantmin question is ?
Regards,
Étienne
On Thursday, March 14, 2024, Étienne BERSAC
wrote:
>
> However, I'd prefer if Postgres fails properly. Because the GRANT is
> actually not revoked. This prevent ldap2pg to report an issue in
> handling privileges on such roles.
>
> What do you think of make this warning an error ?
>
>
The choice
13 matches
Mail list logo
