Date: Thu, 12 Jan 2023 09:40:49 -0800
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Refactor recordExtObjInitPriv()
Message-ID: <20230112174049.GA2047702@nathanxps13>
References: <504bc485-6bd6-dd1b-fe10-e7351aeb310d@enterprisedb.com>
 <20230112000437.GA2032194@nathanxps13>
 <54b13402-b8ab-406a-d9a6-3542124ad6cf@enterprisedb.com>
 <1136333.1673544050@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1136333.1673544050@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20230112174049.GA2047702%40nathanxps13>
Precedence: bulk

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