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
This commit is contained in:
parent
5a3240cf6b
commit
78f058411b
@ -2891,13 +2891,25 @@ The commands accepted in replication mode are:
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Every DML message contains an arbitrary relation ID, which can be mapped to
|
Every DML message contains a relation OID, identifying the publisher's
|
||||||
an ID in the Relation messages. The Relation messages describe the schema of the
|
relation that was acted on. Before the first DML message for a given
|
||||||
given relation. The Relation message is sent for a given relation either
|
relation OID, a Relation message will be sent, describing the schema of
|
||||||
because it is the first time we send a DML message for given relation in the
|
that relation. Subsequently, a new Relation message will be sent if
|
||||||
current session or because the relation definition has changed since the
|
the relation's definition has changed since the last Relation message
|
||||||
last Relation message was sent for it. The protocol assumes that the client
|
was sent for it. (The protocol assumes that the client is capable of
|
||||||
is capable of caching the metadata for as many relations as needed.
|
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>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
@ -617,7 +617,10 @@ apply_handle_relation(StringInfo s)
|
|||||||
/*
|
/*
|
||||||
* Handle TYPE message.
|
* Handle TYPE message.
|
||||||
*
|
*
|
||||||
* This is now vestigial; we read the info and discard it.
|
* This implementation pays no attention to TYPE messages; we expect the user
|
||||||
|
* to have set things up so that the incoming data is acceptable to the input
|
||||||
|
* functions for the locally subscribed tables. Hence, we just read and
|
||||||
|
* discard the message.
|
||||||
*/
|
*/
|
||||||
static void
|
static void
|
||||||
apply_handle_type(StringInfo s)
|
apply_handle_type(StringInfo s)
|
||||||
|
Loading…
x
Reference in New Issue
Block a user