Refactor recordExtObjInitPriv()

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

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?

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

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

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.

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

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