Re: Move global variables of pgoutput to plugin private scope.

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Move global variables of pgoutput to plugin private scope.
Дата
Msg-id CAA4eK1JDAh4Aqt3AZEQ0RHSgTQ-6d1_Yk7Ti=VuTOepyYkgAwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Move global variables of pgoutput to plugin private scope.  (Michael Paquier <michael@paquier.xyz>)
Ответы RE: Move global variables of pgoutput to plugin private scope.  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Re: Move global variables of pgoutput to plugin private scope.  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Wed, Sep 27, 2023 at 9:46 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Sep 27, 2023 at 09:39:19AM +0530, Amit Kapila wrote:
> > On Wed, Sep 27, 2023 at 9:10 AM Michael Paquier <michael@paquier.xyz> wrote:
> >> Err, actually, I am going to disagree here for the patch of HEAD.  It
> >> seems to me that there is zero need for pgoutput.h and we don't need
> >> to show PGOutputData to the world.  The structure is internal to
> >> Pgoutput.c and used only by its internal static routines.
> >
> > Do you disagree with the approach for the PG16 patch or HEAD? You
> > mentioned HEAD but your argument sounds like you disagree with a
> > different approach for PG16.
>
> Only HEAD where the structure should be moved from pgoutput.h to
> pgoutput.c, IMO.
>

It's like that from the beginning. Now, even if we want to move, your
suggestion is not directly related to this patch as we are just
changing one field, and that too to fix a bug. We should start a
separate thread to gather a broader consensus if we want to move the
exposed structure to an internal file.

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Synchronizing slots from primary to standby
Следующее
От: "Zhijie Hou (Fujitsu)"
Дата:
Сообщение: RE: Move global variables of pgoutput to plugin private scope.