Subject: Re: convert libpq uri-regress tests to tap test

From: Andrew Dunstan <[email-masked]>
Date: Wed, 23 Feb 2022 15:39:25 -0500

On 2/23/22 15:30, Andres Freund wrote:
> Hi,
>
> When verifying that the meson port actually runs all perl based tests I came
> across src/interfaces/libpq/test/regress.pl.  Instead of running tests yet
> another way, it seems better to convert it to a tap test.
>
> I hope others agree?

yes

>
> Where would we want that test to live? Right now we have the slightly odd
> convention that some tap tests live in src/test/{misc,modules,...}. But
> e.g. frontend binary ones are below src/bin/.
>
> For now I've left it in src/interfaces/libpq/test, with the test in
> t/001_uri.pl. But we should at least get rid of the test/...
>
> Perhaps we should just rename src/test/modules/libpq_pipeline to
> src/test/modules/libpq and move uri-regress in there as well?

WFM

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Tom Lane <[email-masked]>
Date: Wed, 23 Feb 2022 15:57:08 -0500

> WFM

+1

			regards, tom lane

---

From: Andres Freund <[email-masked]>
Date: Wed, 23 Feb 2022 13:16:06 -0800

Hi,

> >> src/test/modules/libpq and move uri-regress in there as well?

Cool.

One question on making that happen: Right now the makefiles building C stuff
in src/test/modules all have the contrib-style stanza to build via pgxs.  But
afaics pgxs doesn't support building multiple programs. Which
src/test/modules/libpq would need to.

Aaics there's currently no way to have Mkvcbuild.pm build multiple programs in
one dir via its makefile parsing stuff? Andrew, any suggestions for not
needing to spell this out in both the makefile and Mkvcbuild.pm?

Separately: I don't really understand why we do the whole if USE_PGXS dance in
src/test/modules?

- Andres

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 23 Feb 2022 16:57:02 -0500

> src/test/modules/libpq would need to.

That's my understanding also.

> needing to spell this out in both the makefile and Mkvcbuild.pm?

Well, it should be a SMOC. If you can solve the first problem I'm sure I
can come up with a solution for Mkvcbuild.pm. But until we see the shape
of the pgxs changes, planning for Mkcvbuild.pm changes seems remature.

> Separately: I don't really understand why we do the whole if USE_PGXS dance in

ENOCLUE

cheers

andrew