Re: refactor ownercheck and aclcheck functions

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: refactor ownercheck and aclcheck functions
Date: 2022-11-08 11:16:41
Message-ID: 70b0d108-113d-1556-2423-d01874211e6f@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21.10.22 21:17, Peter Eisentraut wrote:
> On 20.10.22 01:24, Corey Huinker wrote:
>> I'd be inclined to remove the highly used ones as well. That way the
>> codebase would have more examples of object_ownercheck() for readers
>> to see. Seeing the existence of pg_FOO_ownercheck implies that a
>> pg_BAR_ownercheck might exist, and if BAR is missing they might be
>> inclined to re-add it.
>
> We do have several ownercheck and aclcheck functions that can't be
> refactored into this framework right now, so we do have to keep some
> special-purpose functions around anyway.  I'm afraid converting all the
> callers would blow up this patch quite a bit, but it could be done as a
> follow-up patch.
>
>> If we do keep them, would it make sense to go the extra step and turn
>> the remaining six "regular" into static inline functions or even
>> #define-s?
>
> That could make sense.

After considering this again, I decided to brute-force this and get rid
of all the trivial wrapper functions and also several of the special
cases. That way, there is less confusion at the call sites about why
this or that style is used in a particular case. Also, it now makes
sure you can't accidentally use the generic functions when a particular
one should be used.

Attachment Content-Type Size
v2-0001-Refactor-ownercheck-functions.patch text/plain 74.2 KB
v2-0002-Refactor-aclcheck-functions.patch text/plain 99.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karthik Jagadish (kjagadis) 2022-11-08 11:30:44 Tables not getting vacuumed in postgres
Previous Message Thomas Munro 2022-11-08 11:04:33 Re: when the startup process doesn't (logging startup delays)