On Fri, Mar 11, 2022 at 11:12 AM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > This issue of how much backwards compatibility breakage we're willing to > tolerate is just as important as questions about how we would want roles to > work in a green-field development project. The sense I got a year ago, on > this list, was that changing CREATEROLE was acceptable, but changing other > parts of the system, such as how ADMIN OPTION works, would go too far. > > Role ownership did not yet exist, and that was a big motivation in > introducing that concept, because you couldn't credibly say it broke other > existing features. It introduces the new notion that when a superuser > creates a role, the superuser owns it, which is identical to how things > implicitly work today; and when a CREATEROLE non-superuser creates a role, > that role owns the new role, which is different from how it works today, > arguably breaking CREATEROLE's prior behavior. *But it doesn't break > anything else*. > > If we're going to change how ADMIN OPTION works, or how role membership > works, or how inherit/noinherit works, let's first be clear that we are > willing to accept whatever backwards incompatibility that entails. This is > not a green-field development project. The constant spinning around with > regard to how much compatibility we need to preserve is giving me vertigo.
I mean, I agree that the backward compatibility ramifications of every idea need to be considered, but I agree even more that the amount of spinning around here is pretty insane. My feeling is that neither role owners nor tenants introduce any real concerns about backward-compatibility or, for that matter, SQL standards compliance, nonwithstanding Stephen's argument to the contrary. Every vendor extends the standard with their own stuff, and we've done that as well, as we can do it in more places. On the other hand, changing ADMIN OPTION does have compatibility and spec-compliance ramifications. I think Stephen is arguing that we can solve this problem while coming closer to the spec, and I think we usually consider getting closer to the spec to be a sufficient reason for breaking backward compatibility (cf. standard_conforming_strings). But I don't know whether he is correct when he argues that the spec makes admin option on a role sufficient to drop the role. I've never had any luck understanding what the SQL specification is saying about any topic. -- Robert Haas EDB: http://www.enterprisedb.com
