On Thu, Jun 2, 2022 at 3:51 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > I sort of thought http://postgr.es/m/3981966.1646429...@sss.pgh.pa.us > > constituted a completed investigation of this sort. No? > > I didn't think so. It's clear that the spec expects us to track the > grantor, but I didn't chase down what it expects us to *do* with that > information, nor what it thinks the rules are for merging multiple > authorizations.
Hmm, OK. Well, one problem is that I've never had any luck interpreting what the spec says about anything, and I've sort of given up. But even if that were not so, I'm a little unclear what other conclusion is possible here. The spec either wants the same behavior that we already have for other object types, which is what I am here proposing that we do, or it wants something different. If it wants something different, it probably wants that for all object types, not just roles. Since I doubt we would want the behavior for roles to be inconsistent with what we do for all other object types, in that case we would probably either change the behavior for all other object types to something new, and then clean up the role stuff afterwards, or else first do what I proposed here and then later change it all at once. In which case the proposal that I've made is as good a way to start as any. Now, if it happens to be the case that the spec proposes a different behavior for roles than for non-role objects, and if the behavior for roles is something other than the only we currently have for non-role objects, then I'd agree that the plan I propose here needs revision. I suspect that's unlikely but I can't make anything of the spec so .... maybe? -- Robert Haas EDB: http://www.enterprisedb.com