I wrote:
> The major thing that this style of test misses, IMO, is that it
> proves nothing at all about the stability of the binary representation.
> In particular, it'd be almost trivially easy for someone to screw up
> the expectation of endianness independence for the binary format.
> To address that, I think we'd not only want to check the round-trip
> behavior, but also compare the binary output to a "known good"
> reference file. If we messed up on endianness independence, the
> bigendian members of the buildfarm would find it immediately.
I thought of an easier-to-maintain approach to that part than having
a reference file. Binary send functions are invokable from SQL,
so we could just imagine adding test cases along the lines of
regression=# select int8send(42);
int8send
--------------------
\x000000000000002a
(1 row)
for each data type. This would be enough to detect endianness issues,
garbage in padding bytes, etc.
The receive functions are not so easy to call, so we still need a
round-trip test, but you could imagine a TAP test framework for that.
Or, perhaps, the thing to do would be to provide a generic test function
that takes a value, runs it through the type's send and then receive
functions, and returns the result (or just complains if it gets different
bits out ...)
regards, tom lane