Paul Jungwirth <pj@illuminatedcomputing.com> writes:
> On 9/18/19 7:26 AM, Tom Lane wrote:
>> Likely it'd be good to have some more consistent approach to
>> testing that ... right now it's not even very obvious where
>> is a good place to add such tests. I do see a small test in
>> src/test/regress/input/misc.source (COPY BINARY stud_emp),
>> but that solution doesn't scale easily because of its
>> dependence on absolute file pathnames.
> I'm not sure how hard this would be, but we could add a new schema to
> the regression db and then do something like this:
> psql -d regression -c 'COPY public.t TO STDOUT WITH (FORMAT BINARY)' \
> | psql -d regression -c 'COPY binaryio.t FROM STDIN WITH (FORMAT BINARY)'
> and then verify that `SELECT *` looks the same for the two tables. I can
> think of several complications already though. :-)
Yeah, that's more or less what the existing test case does, but only
for a rather small set of types.
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.
(I live in fear that we will, or have already, shipped such a bug
with nobody noticing.)
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.
regards, tom lane