On Sat, Oct 8, 2022 at 11:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Joe Conway <mail@joeconway.com> writes: > > Thanks -- looks good to me. If there are no other comments or concerns, > > I will commit/push by the end of the weekend. > > Robert seems to think that this patch might be completely misguided, > so I'm not sure we have real consensus. I think he may have a point.
I think what is bothering me is a feeling that a privilege is something that you get because you've authenticated. If you haven't authenticated yet, you have no privileges. So why should it matter whether the role to which you could hypothetically authenticate would inherit the privileges of some other role or not?
Or to put it another way, I don't have any intuition for why someone would want the system to behave in this way rather than in the way that it does now.
I'm also in the "inheritance isn't relevant here" camp. One doesn't inherit an ability to LOGIN from a group that has a LOGIN attribute. The [NO]INHERIT attribute doesn't even apply. This feature is so closely related to LOGIN that [NO]INHERIT should likewise not apply here as well.
We've decided to conjoin two arguably orthogonal concerns here and need to keep in mind that any given aspect of the overall capability might very well only apply to a subset of the system. In this case inheritance only applies to object permissions, not attributes, and not authentication (which doesn't have any kind of explicit permission bit in the system to inherit, making it just like LOGIN).
I would tend to agree that even membership probably shouldn't be involved here, and that this entire feature would be implemented in an orthogonal manner. I don't see any specific need to try and move to a more isolated implementation, but trying to involve inheritance just seems wrong. The status quo seems like a good place to stay.
