On Mon, Dec 18, 2023 at 11:35 AM Peter Smith <smithpb2...@gmail.com> wrote: > > Hi, I had a look at the latest v02 patches. > > On Sat, Dec 16, 2023 at 12:36 AM Emre Hasegeli <e...@hasegeli.com> wrote: > > > > > OK, to deal with that can't you just include "origin" in the first > > > group which has no special protocol requirements? > > > > I think it'd be confusing because the option is not available before > > version 16. I think it should really check for the version number and > > complain if it's less than 4. > > Hm. I don't think a proto_version check is required for "origin". > > IIUC, the protocol version number indicates the message byte format. > It's needed so that those messages bytes can be read/written in the > same/compatible way. OTOH I thought the "origin" option has nothing > really to do with actual message formats on the wire; I think it works > just by filtering up-front to decide either to send the changes or not > send the changes. For example, so long as PostgreSQL >= v16, I expect > you could probably use "origin" with any proto_version you wanted. >
But, I don't know how the user would be able to arrange for such a mixture of PG/proto_version versions. because they do seem tightly coupled for pgoutput. e.g. server_version = walrcv_server_version(LogRepWorkerWalRcvConn); options.proto.logical.proto_version = server_version >= 160000 ? LOGICALREP_PROTO_STREAM_PARALLEL_VERSION_NUM : server_version >= 150000 ? LOGICALREP_PROTO_TWOPHASE_VERSION_NUM : server_version >= 140000 ? LOGICALREP_PROTO_STREAM_VERSION_NUM : LOGICALREP_PROTO_VERSION_NUM; ====== Kind Regards, Peter Smith. Fujitsu Australia