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
- v2-0001-Remove-AggregateRelationId-from-recordExtObjInitP.patch (text/plain) patch v2-0001
- v2-0002-Refactor-recordExtObjInitPriv.patch (text/plain) patch v2-0002
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
-
Refactor recordExtObjInitPriv()
- 2a1d7071c4ed 16.0 landed
-
Remove AggregateRelationId from recordExtObjInitPriv()
- 13b345df6438 16.0 landed