Re: role self-revocation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: role self-revocation
Date
Msg-id CA+TgmoZ=1-OBJ12t0XrDmqa7XLWHd2ZgKgkHAS3Ymuwj3Z_cmQ@mail.gmail.com
Whole thread Raw
In response to Re: role self-revocation  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: role self-revocation  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
On Fri, Mar 11, 2022 at 10:37 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> I largely agree and am perfectly fine with going with the majority on this point.  My vote would just fall on the
conservativeside.  But as so far no one else seems to be overly concerned, nerfing CREATEROLE seems to be the path
forward.

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. Moreover, unlike 'SELECT * FROM
table', CREATEROLE is kinda broken, and it's less scary to make
changes to behavior that sucks in the first place than it is to make
changes to the behavior of things that are working well. For all of
that, there's no hard-and-fast rule that we couldn't keep the existing
behavior around, introduce a substitute, and eventually drop the old
thing. I'm just not clear that it's really worth it in this case. It'd
certainly be interesting to hear from anyone who is finding some
utility in the current system. It looks pretty crap to me, but it's
easy to bring too much of one's own bias to such judgements.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: role self-revocation
Next
From: Mark Dilger
Date:
Subject: Re: role self-revocation