Re: fixing CREATEROLE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: fixing CREATEROLE
Date
Msg-id CA+Tgmobs5zABWhdr9Bo664wYhdRUTe5A2E8pn=4LBRbUJux+kg@mail.gmail.com
Whole thread Raw
In response to Re: fixing CREATEROLE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: fixing CREATEROLE
Re: fixing CREATEROLE
Re: fixing CREATEROLE
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Infinite loop while acquiring new TOAST Oid