Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> 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.
> 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
