Re: Refactor recordExtObjInitPriv()

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Nathan Bossart <nathandbossart@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-01-16T11:01:47Z
Lists: pgsql-hackers

Attachments

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.

Commits

  1. Refactor recordExtObjInitPriv()

  2. Remove AggregateRelationId from recordExtObjInitPriv()