On Wed, Sep 7, 2022 at 7:09 PM Stephen Frost <sfrost@snowman.net> wrote:
> Calling this a redesign is over-stating things, imv … and I’d much rather have the per-relation granularity than
predefinedroles for this, so there is that to consider too, perhaps.
I also prefer the finer granularity.
On the question of whether freeing up more privilege bits is a
prerequisite for this patch, I'm a bit on the fence about that. If I
look at the amount of extra work that your review comments have caused
me to do over, let's say, the last three years, and I compare that to
the amount of extra work that the review comments of other people have
caused me to do in the same period of time, you win. In fact, you win
against all of them added together and doubled. I think that as a
general matter you are far too willing to argue vigorously for people
to do work that isn't closely related to their original goals, and
which is at times even opposed to their original goals, and I think
the project would be better off if you tempered that urge.
Now on the other hand, I also do think we need more privilege bits.
You're not alone in making the case that this is a problem which needs
to be solved, and the set of other people who are also making that
argument includes me. At the same time, there is certainly a double
standard here. When Andrew and Tom committed
d11e84ea466b4e3855d7bd5142fb68f51c273567 and
a0ffa885e478f5eeacc4e250e35ce25a4740c487 respectively, we used up 2 of
the remaining 4 bits, bits which other people would have liked to have
used up years ago and they were told "no you can't." I don't believe I
would have been willing to commit those patches without doing
something to solve this problem, because I would have been worried
about getting yelled at by Tom. But now here we are with only 2 bits
left instead of 4, and we're telling the next patch author - who is
not Tom - that he's on the hook to solve the problem.
Well, we do need to solve the problem. But we're not necessarily being
fair about how the work involved gets distributed. It's a heck of a
lot easier for a committer to get something committed to address this
issue than a non-committer, and it's a heck of a lot easier for a
committer to ignore the fact that the problem hasn't been solved and
press ahead anyway, and yet somehow we're trying to dump a problem
that's a decade in the making on Nathan. I'm not exactly sure what to
propose as an alternative, but that doesn't seem quite fair.
--
Robert Haas
EDB: http://www.enterprisedb.com