Dear Melih,
If we do not have to treat the case Shi pointed out[1] as code-level, I agreed to
same option binary because it is simpler.
How is this an issue if we let the binary option do binary copy and not an issue if we have a separate copy_binary option?
You can easily have the similar errors when you set copy_binary=true if a type is missing binary send/receive functions.
And also, as Amit mentioned, the same issue can easily be avoided if binary=false until the initial sync is done. It can be set to true later.
I read the use-cases addressed by Bharath[2]
and I cannot find advantage for case 1 and 3 expect the case that binary functions
are not implemented.
Note that case 3 is already how it works on HEAD. Its advantages, as you already mentioned, is when some types are missing the binary functions.
I think that's why case 3 should be allowed even if a new option is added or not.
Previously I said that the combination of "copy_format = binary" and "copy_data = false"
seemed strange[3], but this approach could solve it and other related ones
automatically.
I think it is quite similar to the case where binary=true and enabled=false. In that case, the format is set but the subscription does not replicate anything. And this is allowed.
copy_binary=true and copy_data=false combination also sets the copy format but does not copy anything. Even if any table will not be copied at that moment, tables which might be added later might need to be copied (by ALTER SUBSCRIPTION). And setting the copy format beforehand can be useful in such cases.
I think we should add description to doc that it is more likely happen to fail
the initial copy user should enable binary format after synchronization if
tables have original datatype.
I tried to explain when binary copy can cause failures in the doc. What exactly do you think is missing?
Best,