> If in future version the general data type is added, the copy command in > binary > format will not work well, right? It is because the inferior version does not > have > recv/send functions for added type. It means that there is a possibility that > replication between different versions may be failed if binary format is > specified. > Therefore, I think we should accept copy_format = binary only when the major > version of servers are the same.
I don't think it's necessary to check versions. Yes, there are situations where binary will fail across major versions. But in many cases it does not. To me it seems the responsibility of the operator to evaluate this risk. And if the operator chooses wrong and uses binary copy across incompatible versions, then it will still fail hard in that case during the copy phase (so still a very early error). So I don't see a reason to check pre-emptively, afaict it will only disallow some valid usecases and introduce more code. Furthermore no major version check is done for "binary = true" either (afaik). The only additional failure scenario that copy_format=binary introduces is when one of the types does not implement a send function on the source. With binary=true, this would continue to work, but with copy_format=binary this stops working. All other failure scenarios that binary encoding of types introduces apply to both binary=true and copy_format=binary (the only difference being in which phase of the replication these failures happen, the apply or the copy phase). > I'm not sure the combination of "copy_format = binary" and "copy_data = false" > should be accepted or not. How do you think? It seems quite useless indeed to specify the format of a copy that won't happen.