Re: Move global variables of pgoutput to plugin private scope.
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-27T03:40:08Z
Lists: pgsql-hackers
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. Doing a codesearch in the Debian repos or just github shows that it is used nowhere else, as well, something not really surprising as the structure is filled and maintained in the file. -- Michael
Commits
-
Move tracking of in_streaming to PGOutputData
- 9210afd3bcd6 17.0 landed
-
Fix the misuse of origin filter across multiple pg_logical_slot_get_changes() calls.
- 54ccfd65868c 17.0 landed
- 8d05be93197c 16.1 landed
-
Fix typos in pgoutput.c
- c868cbfef70a 17.0 landed