> On Mar 11, 2022, at 7:58 AM, Robert Haas <robertmh...@gmail.com> wrote:
>
> This kind of thing is always a judgement call. If we were talking
> about breaking 'SELECT * from table', I'm sure it would be hard to
> convince anybody to agree to do that at all, let alone with no
> deprecation period. Fortunately, CREATEROLE is less used, so breaking
> it will inconvenience fewer people.
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.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
