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: 1. some switches processing the OCLASS enum don't have "default:" cases. This is so that the compiler tells us when we fail to add support for some new object class (and it's been helpful). If we were to 2. all users of getObjectClass would have to include the catalog header specific to every catalog it wants to handle; so tablecmds.c and dependency.c would have to include almost all catalog includes, for example. What this says to me is that ObjectClass is/was a somewhat useful abstraction layer on top of catalog definitions. I'm now not 100% that poking this hole in the abstraction (by expanding use of catalog OIDs at the expense of ObjectClass) was such a great idea. Maybe we want to make ObjectClass *more* useful/encompassing rather than the opposite. (*) I mean Oid getObjectClass(const ObjectAddress *object) { /* only pg_class entries can have nonzero objectSubId */ if (object->classId != RelationRelationId && object->objectSubId != 0) elog(ERROR, "invalid non-zero objectSubId for object class %u", object->classId); return object->classId; } plus #define OCLASS_CLASS RelationRelationId #define OCLASS_PROC ProcedureRelationId #define OCLASS_TYPE TypeRelationId etc. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth)