On Thu, Feb 29, 2024 at 12:41:38PM +0100, Peter Eisentraut wrote: > On 27.02.24 08:57, Alvaro Herrera wrote: >> On 2024-Feb-27, Michael Paquier wrote: >>> These would cause compilation failures. Saying that, this is a very >>> nice cleanup, so I've fixed these and applied the patch after checking >>> that the one-one replacements were correct. >> >> Oh, I thought we were going to get rid of ObjectClass altogether -- I >> mean, have getObjectClass() return ObjectAddress->classId, and then >> define the OCLASS values for each catalog OID [... tries to ...] But >> this(*) doesn't work for two reasons: > > I have long wondered what the point of ObjectClass is. I find the extra > layer of redirection, which is used only in small parts of the code, and the > similarity to ObjectType confusing. I happened to have a draft patch for > its removal lying around, so I'll show it here, rebased over what has > already been done in this thread.
The elimination of getObjectClass() seems like a good end goal IMO, so the direction of the patch is interesting. Would object_type_map and ObjectProperty follow the same idea of relying on the catalogs OID instead of the OBJECT_*? Note that there are still two dependencies to getObjectClass() in event_trigger.c and dependency.c. -- Michael
signature.asc
Description: PGP signature
