On Wed, Sep 7, 2022 at 7:09 PM Stephen Frost <sfr...@snowman.net> wrote: > Calling this a redesign is over-stating things, imv … and I’d much rather > have the per-relation granularity than predefined roles 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
