Thread: Refactor recordExtObjInitPriv()

Refactor recordExtObjInitPriv()

From
Peter Eisentraut
Date:
Another aclchk.c refactoring patch, similar to [0] and [1].

Refactor recordExtObjInitPriv():  Instead of half a dozen of 
mostly-duplicate conditional branches, write one common one that can 
handle most catalogs.  We already have all the information we need, such 
as which system catalog corresponds to which catalog table and which 
column is the ACL column.


[0]: 
https://www.postgresql.org/message-id/95c30f96-4060-2f48-98b5-a4392d3b6066@enterprisedb.com
[1]: 
https://www.postgresql.org/message-id/flat/22c7e802-4e7d-8d87-8b71-cba95e6f4bcf%40enterprisedb.com
Attachment

Re: Refactor recordExtObjInitPriv()

From
Nathan Bossart
Date:
On Tue, Dec 27, 2022 at 09:56:10AM +0100, Peter Eisentraut wrote:
> Refactor recordExtObjInitPriv():  Instead of half a dozen of
> mostly-duplicate conditional branches, write one common one that can handle
> most catalogs.  We already have all the information we need, such as which
> system catalog corresponds to which catalog table and which column is the
> ACL column.

This seems reasonable.

> +    /* This will error on unsupported classoid. */
> +    else if (get_object_attnum_acl(classoid))

nitpick: I would suggest explicitly checking that it isn't
InvalidAttrNumber instead of relying on it always being 0.

> -             classoid == AggregateRelationId ||

I noticed that AggregateRelationId isn't listed in the ObjectProperty
array, so I think recordExtObjInitPriv() will begin erroring for that
classoid instead of ignoring it like we do today.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



Re: Refactor recordExtObjInitPriv()

From
Peter Eisentraut
Date:
On 12.01.23 01:04, Nathan Bossart wrote:
>> -             classoid == AggregateRelationId ||
> I noticed that AggregateRelationId isn't listed in the ObjectProperty
> array, so I think recordExtObjInitPriv() will begin erroring for that
> classoid instead of ignoring it like we do today.

Hmm, we do have some extensions in contrib that add aggregates (citext, 
intagg).  I suspect that the aggregate function is actually registered 
into the extension via its pg_proc entry, so this wouldn't actually 
matter.  But maybe the commenting should be clearer?




Re: Refactor recordExtObjInitPriv()

From
Tom Lane
Date:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 12.01.23 01:04, Nathan Bossart wrote:
> -             classoid == AggregateRelationId ||
>> I noticed that AggregateRelationId isn't listed in the ObjectProperty
>> array, so I think recordExtObjInitPriv() will begin erroring for that
>> classoid instead of ignoring it like we do today.

> Hmm, we do have some extensions in contrib that add aggregates (citext, 
> intagg).  I suspect that the aggregate function is actually registered 
> into the extension via its pg_proc entry, so this wouldn't actually 
> matter.  But maybe the commenting should be clearer?

Yeah, I don't believe that AggregateRelationId is used in object
addresses; we just refer to pg_proc for any kind of function including
aggregates.  Note that there is no "oid" column in pg_aggregate.

            regards, tom lane



Re: Refactor recordExtObjInitPriv()

From
Nathan Bossart
Date:
On Thu, Jan 12, 2023 at 12:20:50PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> On 12.01.23 01:04, Nathan Bossart wrote:
>> -             classoid == AggregateRelationId ||
>>> I noticed that AggregateRelationId isn't listed in the ObjectProperty
>>> array, so I think recordExtObjInitPriv() will begin erroring for that
>>> classoid instead of ignoring it like we do today.
> 
>> Hmm, we do have some extensions in contrib that add aggregates (citext, 
>> intagg).  I suspect that the aggregate function is actually registered 
>> into the extension via its pg_proc entry, so this wouldn't actually 
>> matter.  But maybe the commenting should be clearer?
> 
> Yeah, I don't believe that AggregateRelationId is used in object
> addresses; we just refer to pg_proc for any kind of function including
> aggregates.  Note that there is no "oid" column in pg_aggregate.

Got it, thanks for clarifying.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



Re: Refactor recordExtObjInitPriv()

From
Peter Eisentraut
Date:
On 12.01.23 18:40, Nathan Bossart wrote:
> On Thu, Jan 12, 2023 at 12:20:50PM -0500, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>> On 12.01.23 01:04, Nathan Bossart wrote:
>>> -             classoid == AggregateRelationId ||
>>>> I noticed that AggregateRelationId isn't listed in the ObjectProperty
>>>> array, so I think recordExtObjInitPriv() will begin erroring for that
>>>> classoid instead of ignoring it like we do today.
>>
>>> Hmm, we do have some extensions in contrib that add aggregates (citext,
>>> intagg).  I suspect that the aggregate function is actually registered
>>> into the extension via its pg_proc entry, so this wouldn't actually
>>> matter.  But maybe the commenting should be clearer?
>>
>> Yeah, I don't believe that AggregateRelationId is used in object
>> addresses; we just refer to pg_proc for any kind of function including
>> aggregates.  Note that there is no "oid" column in pg_aggregate.
> 
> Got it, thanks for clarifying.

I have updated the patch as you suggested and split out the aggregate 
issue into a separate patch for clarity.

Attachment

Re: Refactor recordExtObjInitPriv()

From
Nathan Bossart
Date:
On Mon, Jan 16, 2023 at 12:01:47PM +0100, Peter Eisentraut wrote:
> I have updated the patch as you suggested and split out the aggregate issue
> into a separate patch for clarity.

LGTM

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



Re: Refactor recordExtObjInitPriv()

From
Peter Eisentraut
Date:
On 16.01.23 23:43, Nathan Bossart wrote:
> On Mon, Jan 16, 2023 at 12:01:47PM +0100, Peter Eisentraut wrote:
>> I have updated the patch as you suggested and split out the aggregate issue
>> into a separate patch for clarity.
> 
> LGTM

committed