On 2020-07-14 22:28:48 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > What is the gain in having these checks? recv functions need to be safe > > against arbitrary input, so a type crosscheck doesn't buy additional > > safety in that regard. Not that a potential attacker couldn't just > > change the content anyways? > > You're confusing security issues with user-friendliness issues. > Detecting that you sent the wrong type via an OID mismatch error > is a lot less painful than trying to figure out why you've got > errors along the line of "incorrect binary data format".
An oid mismatch error without knowing what that's about isn't very helpful either.
How about adding an errcontext that shows the "source type oid", the target type oid & type name and, for records, the column name of the target table? That'd make this a lot easier to debug.
So looking at how to confirm that the subscriber has receive functions for all of the types.
AFAICT we don't have that information since the publication determines what is sent?
This code line 482 in proto.c attempts to limit what is sent in binary. We could certainly be more restrictive here.