Re: Move global variables of pgoutput to plugin private scope. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Move global variables of pgoutput to plugin private scope.
Date
Msg-id CAA4eK1Kndbm=GhYf3bPouYbKTh3Aq-b0hSGMF5zA6hzO2X-C5g@mail.gmail.com
Whole thread Raw
In response to Re: Move global variables of pgoutput to plugin private scope.  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Move global variables of pgoutput to plugin private scope.
List pgsql-hackers
On Wed, Sep 27, 2023 at 9:10 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Sep 26, 2023 at 01:55:10PM +0000, Zhijie Hou (Fujitsu) wrote:
> > On Tuesday, September 26, 2023 4:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> Do we really need a new parameter in above structure? Can't we just use the
> >> existing origin in the same structure? Please remember if this needs to be
> >> backpatched then it may not be good idea to add new parameter in the
> >> structure but apart from that having two members to represent similar
> >> information doesn't seem advisable to me. I feel for backbranch we can just use
> >> PGOutputData->origin for comparison and for HEAD, we can remove origin
> >> and just use a boolean to avoid any extra cost for comparisions for each
> >> change.
> >
> > OK, I agree to remove the origin string on HEAD and we can add that back
> > when we support other origin value. I also modified to use the string for comparison
> > as suggested for back-branch. I will also test it locally to confirm it doesn't affect
> > the perf.
>
> 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.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_upgrade and logical replication
Next
From: Michael Paquier
Date:
Subject: Re: Move global variables of pgoutput to plugin private scope.