Re: Handle infinite recursion in logical replication setup

On Wed, Aug 9, 2023 at 10:59 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> Example output using the patch look like this:
>
> SINGLULAR
> test_sub=# create subscription sub_test connection 'dbname=test_pub'
> publication pub_all_at_pub with(origin=NONE);
> WARNING: subscription "sub_test" requested copy_data with origin =
> NONE but might copy data that had a different origin
> DETAIL: The subscription that you are creating has a publication
> ("pub_all_at_pub") containing tables written to by other
> subscriptions.
> HINT: Verify that initial data copied from the publisher tables did
> not come from other origins.
> NOTICE: created replication slot "sub_test" on publisher
> CREATE SUBSCRIPTION
>
> PLURAL
> test_sub=# create subscription sub_test3 connection 'dbname=test_pub'
> publication pub_all_at_pub,pub_s1_at_pub,pub_s2_at_pub
> with(origin=NONE);
> WARNING: subscription "sub_test3" requested copy_data with origin =
> NONE but might copy data that had a different origin
> DETAIL: The subscription that you are creating has publications
> ("pub_s1_at_pub", "pub_all_at_pub") containing tables written to by
> other subscriptions.
> HINT: Verify that initial data copied from the publisher tables did
> not come from other origins.
> NOTICE: created replication slot "sub_test3" on publisher
> CREATE SUBSCRIPTION
>
> ~
>
> I thought above looked fine but if PeterE also does not like the ()
> then the message can be rearranged slightly like below to put the
> offending publications at the end of the message, like this:
>

Okay, I didn't know strings were already quoted but not sure if Round
Brackets () exactly will address the translatability concern.

> DETAIL: The subscription that you are creating has the following
> publications containing tables written to by other subscriptions:
> "pub_s1_at_pub", "pub_all_at_pub"
>

Fair enough. Peter E., do let us know what you think makes sense here?

--
With Regards,
Amit Kapila.