Re: Adding a LogicalRepWorker type field

Поиск
Список
Период
Сортировка
От Peter Smith
Тема Re: Adding a LogicalRepWorker type field
Дата
Msg-id CAHut+PvSpQ+a0DEJ=tZSS95Lr8pTBxKo404=wmHDK-=BexMSTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Adding a LogicalRepWorker type field  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Adding a LogicalRepWorker type field  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: Adding a LogicalRepWorker type field  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yuya Watari
Дата:
Сообщение: Re: [PoC] Reducing planning time when tables have many partitions
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: add timing information to pg_upgrade