question regarding copyData containers

out: Byten4

We loose the semantics of the "row" that copyData has according to the documentation 

https://www.postgresql.org/docs/10/protocol-flow.html#PROTOCOL-COPY  

but it is not a problem because the raw bytes are still parsable (rows + fields) in text mode (tsv) and in binary mode)

Now I started working on copyBoth and logical decoding scenarios. In this case, the server send series of copyData. 1 copyData containing 1 message :

at the network chunk level, in the case of large fields, we can observe

in: CopyData Int32 XLogData Int64  Int64  Int64 Byten1

but at the XLogData level, the protocol is not self-describing its length, so there is no real way of knowing where the first XLogData ends apart from

 - knowing the length of the first copyData (4 + 1 + 3*8 + n1 + n2)

 - knowing the internals of the output plugin and benefit from a plugin that self-describe its span 

when a network chunks contains several copyDatas

in: CopyData Int32 XLogData Int64  Int64  Int64 Byten1  CopyData Int32 XLogData Int64  Int64  Int64 Byten2  

we have

out: XLogData Int64  Int64  Int64 Byten1 XLogData Int64  Int64  Int64 Byten2

and with test_decoding for example it is impossible to know where the test_decoding output ends without remembering the original length of the copyData.

now my question is the following : 

is it ok to consider that over the long term copyData is simply a transport container that exists only to allow the multiplexing of events in the protocol but that messages inside could be chunked over several copyData events ?

if we put test_decoding apart, do you consider that output plugins XLogData should be self-aware of their length ? I suppose (but did not fully verify yet) that this is the case for pgoutput ? I suppose that wal2json could also be parsed by balancing the brackets.

I am wondering because when a client sends copyData to the server, the documentation says

I hope that my message will ring a bell on the list.

I tried the best I could to describe my very specific research.

Thank you for your help,

---

Jérôme