On Sun, Sep 22, 2019 at 11:53 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > 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. 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)? > 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 ...) 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? 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. Should I move this thread over to pgsql-hackers for this? Paul
