Re: PGDOCS - Replica Identity quotes - Mailing list pgsql-hackers

From David Zhang
Subject Re: PGDOCS - Replica Identity quotes
Date
Msg-id 8878bf9b-2379-e8a1-5cd5-ec956144e957@highgo.ca
Whole thread Raw
In response to Re: PGDOCS - Replica Identity quotes  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: PGDOCS - Replica Identity quotes  (Peter Smith <smithpb2250@gmail.com>)
List pgsql-hackers
On 2023-03-16 4:46 p.m., Peter Smith wrote:
> A rebase was needed due to the recent REPLICA IDENTITY push [1].
>
> PSA v2.
>
>     <para>
> -   A published table must have a <quote>replica identity</quote> configured in
> +   A published table must have a <firstterm>replica identity</firstterm> configured in
+1
>      order to be able to replicate <command>UPDATE</command>
>      and <command>DELETE</command> operations, so that appropriate rows to
>      update or delete can be identified on the subscriber side.  By default,
>      this is the primary key, if there is one.  Another unique index (with
>      certain additional requirements) can also be set to be the replica
>      identity.  If the table does not have any suitable key, then it can be set
> -   to replica identity <quote>full</quote>, which means the entire row becomes
> -   the key.  When replica identity <quote>full</quote> is specified,
> +   to <literal>REPLICA IDENTITY FULL</literal>, which means the entire row becomes
> +   the key.  When <literal>REPLICA IDENTITY FULL</literal> is specified,
>      indexes can be used on the subscriber side for searching the rows.  Candidate
>      indexes must be btree, non-partial, and have at least one column reference
>      (i.e. cannot consist of only expressions).  These restrictions
>      on the non-unique index properties adhere to some of the restrictions that
>      are enforced for primary keys.  If there are no such suitable indexes,
>      the search on the subscriber side can be very inefficient, therefore
> -   replica identity <quote>full</quote> should only be used as a
> +   <literal>REPLICA IDENTITY FULL</literal> should only be used as a
>      fallback if no other solution is possible.  If a replica identity other
IMO, it would be better just change "full" to "FULL". On one side, it 
can emphasize that "FULL" is one of the specific values (DEFAULT | USING 
INDEX index_name | FULL | NOTHING); on the other side, it leaves 
"replica identity" in lowercase to be more consistent with the 
terminology used in this entire paragraph.
> -   than <quote>full</quote> is set on the publisher side, a replica identity
> +   than <literal>FULL</literal> is set on the publisher side, a replica identity
+1
>      comprising the same or fewer columns must also be set on the subscriber
>      side.  See <xref linkend="sql-altertable-replica-identity"/> for details on
>      how to set the replica identity.  If a table without a replica identity is

David




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: MERGE lacks ruleutils.c decompiling support!?
Next
From: Francisco Luis Arbelaez Lopez
Date:
Subject: Bancolombia Open Source Program Office - Proposal of contribution on lock inactive users