On 01.03.24 05:08, Michael Paquier wrote:
> 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.
Oops, there was a second commit in my branch that I neglected to send
in. Here is my complete patch set.