On 9/18/19 7:26 AM, Tom Lane wrote:
> The core regression tests don't systematically exercise binary I/O,
> and they certainly wouldn't magically cover a new type they didn't
> use to. You'd need to add test case(s).
Thanks! I thought psql might use binary IO internally when available, or
at least pg_dump with its custom format, but it looks like neither of
those are true---and now that I think about it I suppose the code in adt
isn't something they would be able to use, so it makes sense.
So I guess my choices are to use COPY WITH (FORMAT BINARY) or write
something that calls PQexecParams. Does anything else use binary I/O?
> 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. :-)
But even if that's not an automated test at least it gives me an easy
way to manually exercise my own multirange_{send,recv} functions.
Thanks!
--
Paul ~{:-)
pj@illuminatedcomputing.com
