Doc: improve protocol spec for logical replication Type messages.

protocol.sgml documented the layout for Type messages, but completely
dropped the ball otherwise, failing to explain what they are, when
they are sent, or what they're good for.  While at it, do a little
copy-editing on the description of Relation messages.

In passing, adjust the comment for apply_handle_type() to make it
clearer that we choose not to do anything when receiving a Type
message, not that we think it has no use whatsoever.

Per question from Stefen Hillman.

Discussion: https://postgr.es/m/CAPgW8pMknK5pup6=T4a_UG=Cz80Rgp=KONqJmTdHfaZb0RvnFg@mail.gmail.com

1 files changed, 19 insertions, 7 deletions

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index b692648fca..84ddab0998 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2891,13 +2891,25 @@ The commands accepted in replication mode are:
   </para>
 
   <para>
-   Every DML message contains an arbitrary relation ID, which can be mapped to
-   an ID in the Relation messages. The Relation messages describe the schema of the
-   given relation. The Relation message is sent for a given relation either
-   because it is the first time we send a DML message for given relation in the
-   current session or because the relation definition has changed since the
-   last Relation message was sent for it. The protocol assumes that the client
-   is capable of caching the metadata for as many relations as needed.
+   Every DML message contains a relation OID, identifying the publisher's
+   relation that was acted on.  Before the first DML message for a given
+   relation OID, a Relation message will be sent, describing the schema of
+   that relation.  Subsequently, a new Relation message will be sent if
+   the relation's definition has changed since the last Relation message
+   was sent for it.  (The protocol assumes that the client is capable of
+   remembering this metadata for as many relations as needed.)
+  </para>
+
+  <para>
+   Relation messages identify column types by their OIDs.  In the case
+   of a built-in type, it is assumed that the client can look up that
+   type OID locally, so no additional data is needed.  For a non-built-in
+   type OID, a Type message will be sent before the Relation message,
+   to provide the type name associated with that OID.  Thus, a client that
+   needs to specifically identify the types of relation columns should
+   cache the contents of Type messages, and first consult that cache to
+   see if the type OID is defined there.  If not, look up the type OID
+   locally.
   </para>
  </sect2>
 </sect1>