Re: Adding a LogicalRepWorker type field - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Adding a LogicalRepWorker type field
Date
Msg-id CAHut+PvSpQ+a0DEJ=tZSS95Lr8pTBxKo404=wmHDK-=BexMSTQ@mail.gmail.com
Whole thread Raw
In response to Re: Adding a LogicalRepWorker type field  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Adding a LogicalRepWorker type field
Re: Adding a LogicalRepWorker type field
List pgsql-hackers
On Wed, Aug 2, 2023 at 1:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Aug 2, 2023 at 8:10 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> >
> > The am_xxx functions are removed now in the v2-0001 patch. See [1].
> >
> > The replacement set of macros (the ones with no arg) are not strictly
> > necessary, except I felt it would make the code unnecessarily verbose
> > if we insist to pass MyLogicalRepWorker everywhere from the callers in
> > worker.c / tablesync.c / applyparallelworker.c.
> >
>
> Agreed but having a dual set of macros is also not clean. Can we
> provide only a unique set of inline functions instead?
>

We can't use the same names for both with/without-parameter functions
because there is no function overloading in C. In patch v3-0001 I've
replaced the "dual set of macros", with a single inline function of a
different name, and one set of space-saving macros.

PSA v3

------
Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: Yuya Watari
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions
Next
From: Peter Eisentraut
Date:
Subject: Re: add timing information to pg_upgrade