On Sun, Sep 22, 2019 at 11:53 AM Tom Lane <tgl@sss.pgh.pa.us> 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
