Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL

>> Is this restriction only for the subscriber?
>>
>> If we have not changed the replica identity and there is no primary key, then we forbid update and delete on the publication side (a fairly common usage error at the beginning of using publications).
>> If we have replica identity FULL (the table has such a column), then on the subscription side, update and delete will be performed.
>
> In the above sentence, do you mean the publisher side?

Yep, sorry.

> But we will not be able to apply them on a subscription. Right?
>
> If your previous sentence talks about the publisher and this sentence
> about the subscriber then what you are saying is correct. You can see
> the example in the email [1].

Thank you

>> This is an important difference for real use, when the subscriber is not necessarily postgresql - for example, debezium.
>
> Can you explain the difference and problem you are seeing? As per my
> understanding, this is the behavior from the time logical replication
> has been introduced.

The difference is that if it's a subscriber-only restriction, then it won't automatically apply to anyone with a non-postgresql subscriber.
But if suddenly this would be a limitation of the publisher - then it will automatically apply to everyone, regardless of which subscriber is used.
(and it's a completely different problem if the restriction affects the update/delete themselves, not only their replication. Like as default replica identity on table without primary key, not in this case)

So, I suggest to mention subscriber explicitly:

+ class of Btree, then <literal>UPDATE</literal> and <literal>DELETE</literal>
- operations cannot be replicated.
+ operations cannot be applied on subscriber.

Another example of difference:
Debezium users sometimes ask to set identity to FULL to get access to old values: https://stackoverflow.com/a/59820210/10983392
However, identity FULL is described in the documentation as: https://www.postgresql.org/docs/current/logical-replication-publication.html

> If the table does not have any suitable key, then it can be set to replica identity “full”, which means the entire row becomes the key. This, however, is very inefficient and should only be used as a fallback if no other solution is possible.

But not mentioned, this would only be "very inefficient" for the subscriber, or would have an huge impact on the publisher too (besides writing more WAL).

regards, Sergei