Re: When does Postgres use binary I/O?

Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> writes:
> On Sun, Sep 22, 2019 at 11:53 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I thought of an easier-to-maintain approach to that part than having
>> a reference file.

> I just finished my multirange patch (well, "finished" :-), so I might
> be willing to sign up for this. Would you scatter these tests around
> in the various existing files? Or add a new cross-cutting file (like
> opr_sanity etc)?

I think adding them to the existing datatype-specific regression tests
is probably the way to go. It seems like it'd be more likely that
someone writing a new datatype would emulate one of those test scripts
than that they'd notice they ought to add a section to some other
script.

> So you're saying the latter option is to add a new function that
> someone can call from SQL, that just round-trips a value through send
> + recv? And then call that from an ordinary regress test?

Yeah, something roughly like "send_recv_round_trip(any) returns bool",
I guess.

> I guess the
> tests themselves can't define the function (like they define
> binary_coercible), because you need to call *_recv from C, so this
> would actually be a function we ship and document, right? That seems
> within my abilities.

I'm not sure we'd want to expose it as a generally available function.
One idea is to put it in regress.c, although most of the functions
in there today are not created till create_function_1.sql which runs
too late to be useful for this. Maybe it's okay as a core function.

> Should I move this thread over to pgsql-hackers for this?

Yeah.

regards, tom lane