Re: Time delayed LR (WAS Re: logical replication restrictions)

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Time delayed LR (WAS Re: logical replication restrictions)
Дата
Msg-id CAA4eK1KhNABpZQq4UfQwUMCFZ4fAZUcFwtgLMoiD2dV3sMsotQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Time delayed LR (WAS Re: logical replication restrictions)  (Peter Smith <smithpb2250@gmail.com>)
Список pgsql-hackers
On Tue, Jan 24, 2023 at 3:46 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Mon, Jan 23, 2023 at 9:44 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> >
> > > 6. defGetMinApplyDelay
> > >
> ...
> > >
> > > 6b.
> > > I thought this function should be implemented as static and located at
> > > the top of the subscriptioncmds.c source file.
> > >
> >
> > I agree that this should be a static function but I think its current
> > location is a better place as other similar function is just above it.
> >
>
> But, why not do everything, instead of settling on a half-fix?
>
> e.g.
> 1. Change the new function (defGetMinApplyDelay) to be static as it should be
> 2. And move defGetMinApplyDelay to the top of the file where IMO it
> really belongs
> 3. And then remove the (now) redundant forward declaration of
> defGetMinApplyDelay
> 4. And also move the existing function (defGetStreamingMode) to the
> top of the file so that those similar functions (defGetMinApplyDelay
> and defGetStreamingMode) can remain together
>

There are various other static functions (merge_publications,
check_duplicates_in_publist, etc.) which then also needs similar
change. BTW, I don't think we have a policy to always define static
functions before their usage. So, I don't see the need to do anything
in this matter.

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Mutable CHECK constraints?
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Time delayed LR (WAS Re: logical replication restrictions)