Date: Wed, 11 Jan 2023 16:04:37 -0800
From: Nathan Bossart <nathandbossart@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Refactor recordExtObjInitPriv()
Message-ID: <20230112000437.GA2032194@nathanxps13>
References: <504bc485-6bd6-dd1b-fe10-e7351aeb310d@enterprisedb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <504bc485-6bd6-dd1b-fe10-e7351aeb310d@enterprisedb.com>
Archived-At: <https://www.postgresql.org/message-id/20230112000437.GA2032194%40nathanxps13>
Precedence: bulk

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