MIME-Version: 1.0
References: <CALDaNm0gwjY_4HFxvvty01BOT01q_fJLKQ3pWP9=9orqubhjcQ@mail.gmail.com>
 <TYAPR01MB5866C758B1185217950ED13CF5029@TYAPR01MB5866.jpnprd01.prod.outlook.com>
 <CALDaNm0WSo5369pr2eN1obTGBeiJU9cQdF6Ju1sC4hMQNy5BfQ@mail.gmail.com>
 <CAHut+PsAWaETh9VMymbBfMrqiE1KuqMq+wpBg0s7eMzwLATr+w@mail.gmail.com>
 <CALDaNm3GQFVGeKg18wUe1-toXd_80=AW+JOW9KQySVbL8Tz4WA@mail.gmail.com>
 <CAHut+PtRxiQR_4UFLNThg-NNRV447FvwtcR-BvqMzjyMJXKwfw@mail.gmail.com>
 <CALDaNm2ttHxORgvtzd3ZFZe7-uLjfrAX3WSM-Wxf5Et_CVm41Q@mail.gmail.com>
 <CAHut+PvQonJd5epJBM0Yfh1499mL9kTL9a=GrMhvnL6Ok05zqw@mail.gmail.com>
 <CALDaNm3jkotRhKfCqu5CXOf36_yiiW_cYE5=bG=j6N3gOWJkqw@mail.gmail.com>
 <CAExHW5vY9QE0QQyYaCBaMKpvjA2h+AwSk6Y4R9LivK=FnX_OjQ@mail.gmail.com>
 <CAA4eK1+Mtz+StvNNtTg9=9BTq8=pMu-V5i4yWqs=KJUh0Z_L4g@mail.gmail.com>
 <CALDaNm0SrCcf8tHtpoE6Zjk-xSg4+6eHDRh2NsWBNVxbe7xbtw@mail.gmail.com> <CAHut+Pu7=cmy7cw8Oc1mss-3NqSMHvw2UxW-APqW9-sFK1OhEA@mail.gmail.com>
In-Reply-To: <CAHut+Pu7=cmy7cw8Oc1mss-3NqSMHvw2UxW-APqW9-sFK1OhEA@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Tue, 8 Mar 2022 10:51:08 +0530
Message-ID: <CAA4eK1Lk=v=EtTzsPcsjkrAY1F9uOLJdmNq1uRvvagdE=OyDxw@mail.gmail.com>
Subject: Re: Handle infinite recursion in logical replication setup
To: Peter Smith <smithpb2250@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, 
	"kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1Lk%3Dv%3DEtTzsPcsjkrAY1F9uOLJdmNq1uRvvagdE%3DOyDxw%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 8, 2022 at 10:31 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> IIUC the new option may be implemented subscriber-side and/or
> publisher-side and/or both, and the subscriber-side option may be
> "enhanced" in future to prevent cycles. And probably there are more
> features I don't know about or that have not yet been thought of.
>
> ~~
>
> Even if the plan is only to implement just one part now and then add
> more later, I think there still should be some consideration for what
> you expect all possible future options to look like, because that may
> affect current implementation choices.
>
> The point is:
>
> - we should take care so don't accidentally end up with an option that
> turned out to be inconsistent looking on the subscriber-side /
> publisher-side.
>
> - we should try to avoid accidentally painting ourselves into a corner
> (e.g. stuck with a boolean option that cannot be enhanced later on)
>

Agreed. I think it is important to see we shouldn't do something which
is not extendable in future or paint us in the corner. But, as of now,
with the current proposal, the main thing we should consider is
whether exposing the boolean option is okay or shall we do something
different so that we can extend it later to specific origin ids?

-- 
With Regards,
Amit Kapila.