| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jacob Champion <pchampion(at)vmware(dot)com> |
| Cc: | "andrew(at)dunslane(dot)net" <andrew(at)dunslane(dot)net>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "peter(dot)eisentraut(at)enterprisedb(dot)com" <peter(dot)eisentraut(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: convert libpq uri-regress tests to tap test |
| Date: | 2022-02-24 17:35:43 |
| Message-ID: | 20220224173543.q7vbubrd767ok2lo@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-02-24 17:03:33 +0000, Jacob Champion wrote:
> On Thu, 2022-02-24 at 08:46 -0800, Andres Freund wrote:
> > One annoying bit is that our current tap invocation infrastructure for msvc
> > won't know how to deal with that. We put the build directory containing t/
> > onto PATH, but that won't work for test/. But we also don't want to install
> > test binaries. Not sure what the solution for that is.
>
> Would it help if the C executable, not Perl, was the thing actually
> producing the TAP output? The binaries built from test/ could be placed
> into t/. Or does that just open up a new set of problems?
I don't think it would help that much. And for the libpq pipeline test it
doesn't really make sense anyway, because we intentionally use it with
different traces and such.
I've thought about a few C tap tests that I'd like, but I think that's a
separate discussion.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-02-24 17:55:53 | Re: remove more archiving overhead |
| Previous Message | Tom Lane | 2022-02-24 17:20:38 | Re: libpq async duplicate error results |