On Wed, Aug 31, 2022 at 8:56 AM Robert Haas <robertmh...@gmail.com> wrote: > In order to apply this patch, we'd need to reach a conclusion about > the matters mentioned in > http://postgr.es/m/ca+tgmobheyynw9vrhvolvd8odspbjuu9cbk6tms6owd70hf...@mail.gmail.com > -- and thinking about this patch might shed some light on what we'd > want to do over there.
That thread has not reached an entirely satisfying conclusion. However, the behavior that was deemed outright buggy over there has been fixed. The remaining question is what to do about commands that allow you to give objects to other users (like ALTER <whatever> .. OWNER TO) or commands that allow you to create objects owned by other users (like CREATE DATABASE ... OWNER). I have, in this version, adopted the proposal by Wolfgang Walther on the other thread to make this controlled by the new SET option. This essentially takes the view that the ability to create objects owned by another user is not precisely a privilege, and is thus not inherited just because the INHERIT option is set on the GRANT, but it is something you can do if you could SET ROLE to that role, so we make it dependent on the SET option. This logic is certainly debatable, but it does have the practical advantage of making INHERIT TRUE, SET FALSE a useful combination of settings for predefined roles. It's also 100% backward-compatible, whereas if we made the behavior dependent on the INHERIT option, users could potentially notice behavior changes after upgrading to v16. So I do like this behavior ... but it's definitely arguable whether it's the best thing. At any rate, here's an updated patch that implements it, and to which I've also added a test case. Review appreciated. Thanks, -- Robert Haas EDB: http://www.enterprisedb.com
v2-0001-Add-a-SET-option-to-the-GRANT-command.patch
Description: Binary data