From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Japin Li <japinli(at)hotmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Improve readability by using designated initializers when possible |
Date: | 2024-03-01 07:03:37 |
Message-ID: | CACJufxGgR-OBz2M8aJak2vbOANH-HkmCa6L7D_Lt3Y-wUu6pXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 1, 2024 at 12:08 PM Michael Paquier <michael(at)paquier(dot)xyz> 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.
> --
I refactored dependency.c, event_trigger.c based on
0001-Remove-ObjectClass.patch.
dependency.c already includes a bunch of catalog header files, but
event_trigger.c doesn't.
Now we need to "include" around 30 header files in event_trigger.c,
not sure if it's ok or not.
0001-Remove-ObjectClass.patch
We also need to refactor getObjectIdentityParts's below comments?
/*
* There's intentionally no default: case here; we want the
* compiler to warn if a new OCLASS hasn't been handled above.
*/
since OCLASS is removed.
`bool EventTriggerSupportsObjectClass(ObjectClass objclass)`
change to
`bool EventTriggerSupportsObjectClass(Oid classId)`
I think the function name should also be refactored.
I'm not sure of the new function name, so I didn't change.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Remove-ObjectClass-refactor-dependency.c-event.no-cfbot | application/octet-stream | 7.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-03-01 07:15:45 | Re: Synchronizing slots from primary to standby |
Previous Message | John Naylor | 2024-03-01 06:58:07 | Re: [PoC] Improve dead tuple storage for lazy vacuum |