On 12/28/17 14:22, Stephen Frost wrote:
> Yes, documenting it, at least, is necessary if we're going to go with
> this approach, though I wonder if that will end up making it difficult
> to remove it later if someone gets around to reworking the GRANT system
> to directly deal with this ambiguity without needing a special-case in
> the object address system for it. I guess one question coming out of
> this is- do you see another use for this OBJECT_RELATION object type..?
> If it's really only this one special case in GRANT that needs it then I
> think that makes it much less appealing to have.
So I was looking into how we can do it without OBJECT_RELATION. For the
first patch, that was obviously easy, because that's what my initial
proposal did. We just treat OBJECT_TABLE within the context of
GRANT/REVOKE as "might also be another kind of relation".
The second class replaced ACL_KIND_CLASS with OBJECT_RELATION in the
context of aclcheck_error(), so that was harder to unwind. But I wrote
some additional code that resolves the actual relkind and gives a more
precise error message, e.g., about "view" or "index" instead of just
"relation". So overall this is a net win, I think.
Attached is an updated patch set. It's a bit messy because I first want
to get confirmation on the approach we are choosing, and then I can
smash them together in the right way. 0001 and 0002 are the original
patches, and then 0003, 0004, 0005 undo the OBJECT_RELATION addition and
replace them with new facilities.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
