Joe Conway <mail@joeconway.com> writes:
> On 3/21/21 12:27 PM, Tom Lane wrote:
>> I think we may have to adjust the acl.c APIs, or maybe better provide new
>> entry points, so that we can have variants of pg_xxx_aclcheck that won't
>> throw a hard error upon not finding the row. We cheesily tried to avoid
>> adjusting those APIs to support the semantics we need here, and we now see
>> that it didn't really work.
> Ok, I took a shot at that; see attached.
Looks generally reasonable by eyeball. The lack of any documentation
comment for the new functions makes me itch, although the ones that
are there are hardly better.
> 1. I confined the changes to just pg_class_aclcheck/mask
> and pg_attribute_aclcheck/mask -- did you intend
> that we do this same change across the board? Or
> perhaps do the rest of them once we open up pg15
> development?
In principle, it might be nice to fix all of those functions in acl.c
to be implemented similarly --- you could get rid of the initial
SearchSysCacheExists calls in the ones that are trying not to throw
error for is-missing cases. In practice, as long as there's no
reachable bug for the other cases, there are probably better things
to spend time on.
> 2. This seems more invasive than something we would want
> to back patch -- agreed?
You could make an argument either way, but given the limited number
of complaints about this, I'd lean to no back-patch.
regards, tom lane
