Re: role self-revocation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: role self-revocation
Дата
Msg-id CA+TgmoZ=1-OBJ12t0XrDmqa7XLWHd2ZgKgkHAS3Ymuwj3Z_cmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: role self-revocation  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: role self-revocation  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: role self-revocation
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: role self-revocation