Re: fixing CREATEROLE

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: fixing CREATEROLE
Дата
Msg-id CA+Tgmobs5zABWhdr9Bo664wYhdRUTe5A2E8pn=4LBRbUJux+kg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: fixing CREATEROLE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: fixing CREATEROLE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: fixing CREATEROLE  (Robert Haas <robertmhaas@gmail.com>)
Re: fixing CREATEROLE  (walther@technowledgy.de)
Список pgsql-hackers
On Mon, Nov 28, 2022 at 4:19 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> That's fine, but are you saying this patch is incapable (or simply undesirable) of having the parts about handling
defaultsseparated out from the parts that define how the system works with a given set of permissions; and the one
implementationdetail of having the bootstrap superuser automatically grant admin to any roles a createuser role
creates?If you and others feel strongly about defaults I'm sure that the suggested other thread focused on that will
getattention and be committed in a timely manner.  But the system will work, and not be broken, if that got stalled,
andit could be added in later. 

The topics are so closely intertwined that I don't believe that trying
to have separate discussions will be useful or productive. There's no
hope of anybody understanding 0004 or having an educated opinion about
it without first understanding the earlier patches, and there's no
requirement that someone has to review 0004, or like it, just because
they review or like 0001-0003.

But so far nobody has actually reviewed anything, and all that's
happened is people have complained about 0004 for reasons which in my
opinion are pretty nebulous and largely ignore the factors that caused
it to exist in the first place. We had about 400 emails during the
last release cycle arguing about a whole bunch of topics related to
user management, and it became absolutely crystal clear in that
discussion that Stephen Frost and David Steele wanted to have roles
that could create other roles but not immediately be able to access
their privileges. Mark and I, on the other hand, wanted to have roles
that could create other roles WITH immediate access to their
privileges. That argument was probably the main thing that derailed
that entire patch set, which represented months of work by Mark. Now,
I have come up with a competing patch set that for the price of 100
lines of code and a couple of slightly ugly option names can do either
thing. So Stephen and David and any like-minded users can have what
they want, and Mark and I and any like-minded users can have what we
want. And the result is that I've got like five people, some of whom
particulated in those discussions, showing up to say "hey, we don't
need the ability to set defaults." Well, if that's the case, then why
did we have hundreds and hundreds of emails within the last 12 months
arguing about which way it should work?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Infinite loop while acquiring new TOAST Oid