Horton

Thread

Commits

  1. Run tests of libpq on installcheck-world, checkprep and check-world

  2. Convert src/interfaces/libpq/test to a tap test.

  3. Run tap tests in src/interfaces/libpq.

  1. convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-23T20:30:31Z

    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?

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?


The tap test needs a bit more polish, mostly posted this to get some feedback
before wasting more time :)

Greetings,

Andres Freund

  2. Re: convert libpq uri-regress tests to tap test

    Andrew Dunstan <andrew@dunslane.net> — 2022-02-23T20:39:25Z

    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

  3. Re: convert libpq uri-regress tests to tap test

    Daniel Gustafsson <daniel@yesql.se> — 2022-02-23T20:40:59Z

    > On 23 Feb 2022, at 21:30, Andres Freund <andres@anarazel.de> wrote:

> 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?

Many +1's on that.

> The tap test needs a bit more polish, mostly posted this to get some feedback
> before wasting more time :)

Skimming the new test it seems structurally fine to me.

--
Daniel Gustafsson		https://vmware.com/

  4. Re: convert libpq uri-regress tests to tap test

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-02-23T20:57:08Z

    Andrew Dunstan <andrew@dunslane.net> writes:
> On 2/23/22 15:30, Andres Freund wrote:
>> Perhaps we should just rename src/test/modules/libpq_pipeline to
>> src/test/modules/libpq and move uri-regress in there as well?

> WFM

+1

			regards, tom lane

  5. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-23T21:16:06Z

    Hi,

On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > On 2/23/22 15:30, Andres Freund wrote:
> >> Perhaps we should just rename src/test/modules/libpq_pipeline to
> >> src/test/modules/libpq and move uri-regress in there as well?
> 
> > WFM
> 
> +1

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

  6. Re: convert libpq uri-regress tests to tap test

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-02-23T21:44:44Z

    On 2022-Feb-23, Andres Freund wrote:

> 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?

WFM.

> Perhaps we should just rename src/test/modules/libpq_pipeline to
> src/test/modules/libpq and move uri-regress in there as well?

Well, building multiple binaries would require some trickery that might
be excessive for this little tool.  But +1 to that on principle.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
"La virtud es el justo medio entre dos defectos" (Aristóteles)

  7. Re: convert libpq uri-regress tests to tap test

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-02-23T21:46:34Z

    On 2022-Feb-23, Andres Freund wrote:

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

Yeah, it seems a bit silly.  I'm not opposed to making these makefiles
unconditionally do the PGXS thing -- or the non-PGXS thing, if that
makes it easier to build multiple binaries.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
"La grandeza es una experiencia transitoria.  Nunca es consistente.
Depende en gran parte de la imaginación humana creadora de mitos"
(Irulan)

  8. Re: convert libpq uri-regress tests to tap test

    Andrew Dunstan <andrew@dunslane.net> — 2022-02-23T21:57:02Z

    On 2/23/22 16:16, Andres Freund wrote:
> Hi,
>
> On 2022-02-23 15:57:08 -0500, Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> On 2/23/22 15:30, Andres Freund wrote:
>>>> Perhaps we should just rename src/test/modules/libpq_pipeline to
>>>> src/test/modules/libpq and move uri-regress in there as well?
>>> WFM
>> +1
> 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.


That's my understanding also.


>
> 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?


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
> src/test/modules?
>

ENOCLUE


cheers


andrew


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

  9. Re: convert libpq uri-regress tests to tap test

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-02-23T22:03:56Z

    Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2022-Feb-23, Andres Freund wrote:
>> Separately: I don't really understand why we do the whole if USE_PGXS dance in
>> src/test/modules?

> Yeah, it seems a bit silly.  I'm not opposed to making these makefiles
> unconditionally do the PGXS thing -- or the non-PGXS thing, if that
> makes it easier to build multiple binaries.

Agreed, we could easily lose that.  I think we only do it in contrib
to serve as an example of how to use PGXS ... although considering
we're not *testing* that build mode, one wonders how much that proves.
In any case, src/test/modules doesn't have to do it.

			regards, tom lane

  10. Re: convert libpq uri-regress tests to tap test

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-02-23T22:53:17Z

    On 23.02.22 21:30, Andres Freund wrote:
> hen 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?
> 
> 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/.

libpq TAP tests should be in src/interfaces/libpq/t/.

I think there were issues that the build farm wouldn't pick up a test 
located there, but that should be fixed rather than worked around.

  11. Re: convert libpq uri-regress tests to tap test

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-02-23T22:58:37Z

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 23.02.22 21:30, Andres Freund wrote:
>> 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/.

> libpq TAP tests should be in src/interfaces/libpq/t/.

> I think there were issues that the build farm wouldn't pick up a test 
> located there, but that should be fixed rather than worked around.

That's failing to account for the fact that a libpq test can't
really be a pure-perl TAP test; you need some C code to drive the
library.  I don't agree with intermixing such code with libpq
itself, independently of any buildsystem issues (which there
might well be).  So I think the design of putting such tests under
src/modules is fine.

			regards, tom lane

  12. Re: convert libpq uri-regress tests to tap test

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-02-23T23:21:36Z

    On 23.02.22 23:58, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> On 23.02.22 21:30, Andres Freund wrote:
>>> 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/.
> 
>> libpq TAP tests should be in src/interfaces/libpq/t/.
> 
>> I think there were issues that the build farm wouldn't pick up a test
>> located there, but that should be fixed rather than worked around.
> 
> That's failing to account for the fact that a libpq test can't
> really be a pure-perl TAP test; you need some C code to drive the
> library.  I don't agree with intermixing such code with libpq
> itself, independently of any buildsystem issues (which there
> might well be).

Such things could be put under src/interfaces/libpq/test, or some other 
subdirectory.  We already have src/interfaces/ecpg/test.

> So I think the design of putting such tests under
> src/modules is fine.

I don't get what the rationale for that would be.  libpq tests are not 
"modules" of any kind.

If I'm working on libpq, I want to do make && make check inside the 
libpq source directory.

  13. Re: convert libpq uri-regress tests to tap test

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-02-24T01:52:41Z

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 23.02.22 23:58, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>> libpq TAP tests should be in src/interfaces/libpq/t/.

>> That's failing to account for the fact that a libpq test can't
>> really be a pure-perl TAP test; you need some C code to drive the
>> library.

> Such things could be put under src/interfaces/libpq/test, or some other 
> subdirectory.  We already have src/interfaces/ecpg/test.

OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
which isn't what you said.  I have no great objection to moving
src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
though, as long as the buildfarm will cope.

			regards, tom lane

  14. Re: convert libpq uri-regress tests to tap test

    Andrew Dunstan <andrew@dunslane.net> — 2022-02-24T12:19:39Z

    On 2/23/22 20:52, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> On 23.02.22 23:58, Tom Lane wrote:
>>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>>> libpq TAP tests should be in src/interfaces/libpq/t/.
>>> That's failing to account for the fact that a libpq test can't
>>> really be a pure-perl TAP test; you need some C code to drive the
>>> library.
>> Such things could be put under src/interfaces/libpq/test, or some other 
>> subdirectory.  We already have src/interfaces/ecpg/test.
> OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
> which isn't what you said.  I have no great objection to moving
> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
> though, as long as the buildfarm will cope.
>
> 			


It won't without some adjustment.


cheers


andrew

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

  15. Re: convert libpq uri-regress tests to tap test

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-02-24T12:31:40Z

    On 24.02.22 02:52, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> On 23.02.22 23:58, Tom Lane wrote:
>>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>>> libpq TAP tests should be in src/interfaces/libpq/t/.
> 
>>> That's failing to account for the fact that a libpq test can't
>>> really be a pure-perl TAP test; you need some C code to drive the
>>> library.
> 
>> Such things could be put under src/interfaces/libpq/test, or some other
>> subdirectory.  We already have src/interfaces/ecpg/test.
> 
> OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
> which isn't what you said.  I have no great objection to moving
> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
> though, as long as the buildfarm will cope.

I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. 
The supporting code snippets could live in some other directory under 
src/interfaces/libpq/, which might be called "test" or something else, 
not that important.

I think we should pick a layout that is proper and future-proof and then 
adjust the buildfarm client as necessary.  The issue of writing 
libpq-specific tests has come up a few times recently; I think it would 
be worth finding a proper solution to this that would facilitate that 
work in the future.

  16. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-24T14:43:11Z

    Hi,

On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
> supporting code snippets could live in some other directory under
> src/interfaces/libpq/, which might be called "test" or something else, not
> that important.

Why not in t/? We can't easily build the test programs in libpq/ itself, but
libpq/t should be fairly doable.

Greetings,

Andres Freund

  17. Re: convert libpq uri-regress tests to tap test

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-02-24T15:17:28Z

    Andres Freund <andres@anarazel.de> writes:
> On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
>> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
>> supporting code snippets could live in some other directory under
>> src/interfaces/libpq/, which might be called "test" or something else, not
>> that important.

> Why not in t/? We can't easily build the test programs in libpq/ itself, but
> libpq/t should be fairly doable.

I think that having t/ directories contain only Perl test scripts
is a good convention that we should stick to.  Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.

			regards, tom lane

  18. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-24T16:46:23Z

    Hi,

On 2022-02-24 10:17:28 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-02-24 13:31:40 +0100, Peter Eisentraut wrote:
> >> I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The
> >> supporting code snippets could live in some other directory under
> >> src/interfaces/libpq/, which might be called "test" or something else, not
> >> that important.
>
> > Why not in t/? We can't easily build the test programs in libpq/ itself, but
> > libpq/t should be fairly doable.
>
> I think that having t/ directories contain only Perl test scripts
> is a good convention that we should stick to.  Peter's proposal
> of a separate test/ subdirectory for C test scaffolding is
> probably fine.

That exists today and continues to exist in the patch upthread, so it's easy
;). I just need to move the libpq/test/t to libpq/t and adjust the binary
path.

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.

Even on !windows, we only know how to find "test executables" in tap tests via
PATH. We're in the source dir, so we can't just do test/executable.

I probably just need another coffee, but right now I don't even see how to add
anything to PATH given $(prove_check)'s definition - it ends up with multiple
shells. We can fix that by using && in the definition, which might be a good
thing anyway?

Attached three patches:

0001: Convert src/interfaces/libpq/test to a tap test
0002: Add tap test infrastructure to src/interfaces/libpq
0003: Move libpq_pipeline test into src/interfaces/libpq.

I did 0001 and 0002 in that order because prove errors out with a stacktrace
if no tap tests exist... It might make more sense to commit them together, but
for review it's easier to keep them separate I think.


Andrew, do you have an idea about the feasibility of supporting any of this
with the msvc build?

I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
coverage, because it already doesn't build the test. Once we've ironed that
stuff out, we could do 0003?

Greetings,

Andres Freund

  19. Re: convert libpq uri-regress tests to tap test

    Jacob Champion <pchampion@vmware.com> — 2022-02-24T17:03:33Z

    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?

--Jacob

  20. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-24T17:35:43Z

    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

  21. Re: convert libpq uri-regress tests to tap test

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-02-25T13:32:43Z

    On 24.02.22 16:17, Tom Lane wrote:
> I think that having t/ directories contain only Perl test scripts
> is a good convention that we should stick to.  Peter's proposal
> of a separate test/ subdirectory for C test scaffolding is
> probably fine.

I wonder if there are any conventions in the Perl community about where 
to put test support files relative to the "t" directory.

  22. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-25T17:56:47Z

    Hi,

On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
> I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
> coverage, because it already doesn't build the test. Once we've ironed that
> stuff out, we could do 0003?

From what I can see in the buildfarm client, we'd not loose (nor gain) any
buildfarm coverage either. It doesn't run the test today.

Greetings,

Andres Freund

  23. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-26T01:52:29Z

    Hi,

On 2022-02-25 09:56:47 -0800, Andres Freund wrote:
> On 2022-02-24 08:46:23 -0800, Andres Freund wrote:
> > I'm mildly inclined to only do 0001 and 0002 for now. We'd not loose msvc
> > coverage, because it already doesn't build the test. Once we've ironed that
> > stuff out, we could do 0003?
> 
> From what I can see in the buildfarm client, we'd not loose (nor gain) any
> buildfarm coverage either. It doesn't run the test today.

Attached are rebased patches. I polished 0001, the regress.pl -> 001_uri.pl
conversion some more (although some of perltidy's changes aren't clearly an
improvement).

I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?

Greetings,

Andres Freund

  24. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-02-27T01:46:26Z

    Hi,

On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?

Pushed.  Attached is the remainder, 0003, the move of libpq_pipeline to
src/interfaces/libpq that I'm not planning to push for now.

Regards,

Andres

  25. Re: convert libpq uri-regress tests to tap test

    Andrew Dunstan <andrew@dunslane.net> — 2022-03-01T15:44:27Z

    On 2/24/22 07:19, Andrew Dunstan wrote:
> On 2/23/22 20:52, Tom Lane wrote:
>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>> On 23.02.22 23:58, Tom Lane wrote:
>>>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>>>> libpq TAP tests should be in src/interfaces/libpq/t/.
>>>> That's failing to account for the fact that a libpq test can't
>>>> really be a pure-perl TAP test; you need some C code to drive the
>>>> library.
>>> Such things could be put under src/interfaces/libpq/test, or some other 
>>> subdirectory.  We already have src/interfaces/ecpg/test.
>> OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
>> which isn't what you said.  I have no great objection to moving
>> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
>> though, as long as the buildfarm will cope.
>>
>> 			
>
> It won't without some adjustment.



See
<https://github.com/PGBuildFarm/client-code/commit/ffc0fc029877632e9437af51bd99ace308daf0c8>
and
<https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2022-03-01%2010%3A47%3A22&stg=module-libpq-check>


cheers


andrew


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

  26. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-03-01T15:52:43Z

    Hi, 

On March 1, 2022 7:44:27 AM PST, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>On 2/24/22 07:19, Andrew Dunstan wrote:
>> On 2/23/22 20:52, Tom Lane wrote:
>>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>>> On 23.02.22 23:58, Tom Lane wrote:
>>>>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>>>>>> libpq TAP tests should be in src/interfaces/libpq/t/.
>>>>> That's failing to account for the fact that a libpq test can't
>>>>> really be a pure-perl TAP test; you need some C code to drive the
>>>>> library.
>>>> Such things could be put under src/interfaces/libpq/test, or some other 
>>>> subdirectory.  We already have src/interfaces/ecpg/test.
>>> OK, but then the TAP scripts are under src/interfaces/libpq/test/t,
>>> which isn't what you said.  I have no great objection to moving
>>> src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/,
>>> though, as long as the buildfarm will cope.
>>>
>>> 			
>>
>> It won't without some adjustment.
>
>
>
>See
><https://github.com/PGBuildFarm/client-code/commit/ffc0fc029877632e9437af51bd99ace308daf0c8>
>and
><https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2022-03-01%2010%3A47%3A22&stg=module-libpq-check>

Thanks! 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

  27. Re: convert libpq uri-regress tests to tap test

    Justin Pryzby <pryzby@telsasoft.com> — 2022-04-16T14:44:54Z

    On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> Pushed.  Attached is the remainder, 0003, the move of libpq_pipeline to
> src/interfaces/libpq that I'm not planning to push for now.

I saw that Andrew just pushed something to start building this under MSVC.

In case it's of any interest, I had done this differently a while back.
This probably doesn't apply except on top of some other patches, but you get
the idea.

commit 923f8a1c2cbea35cb01d1599caa2a81e3186181c
Author: Justin Pryzby <pryzbyj@telsasoft.com>
Date:   Mon Feb 28 01:31:10 2022 -0600

    f!
    
    ci-os-only: windows

diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 4364ab943fd..71ec747e544 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -44,6 +44,7 @@ my $contrib_extraincludes  = {};
 my $contrib_extrasource    = {
 	'uri-regress' => ['src/interfaces/libpq/test/uri-regress.c'],
 	'testclient' => ['src/interfaces/libpq/test/testclient.c'],
+	'libpq_pipeline' => ['src/interfaces/libpq/test/libpq_pipeline.c'],
 };
 my @contrib_excludes = (
 	'bool_plperl',      'commit_ts',
@@ -475,7 +476,7 @@ sub mkvcbuild
 		push @contrib_excludes, 'uuid-ossp';
 	}
 
-	foreach my $subdir ('contrib', 'src/test/modules', 'src/interfaces/libpq')
+	foreach my $subdir ('contrib', 'src/test/modules') #, 'src/interfaces/libpq')
 	{
 		opendir($D, $subdir) || croak "Could not opendir on $subdir!\n";
 		while (my $d = readdir($D))
@@ -804,6 +805,20 @@ sub mkvcbuild
 		$p->AddReference($postgres);
 	}
 
+	$mf = Project::read_file('src/interfaces/libpq/test/Makefile');
+	$mf =~ s{\\\r?\n}{}g;
+	$mf =~ m{PROGRAMS\s*=\s*(.*)$}m
+	  || die 'Could not match in src/interfaces/libpq/test/Makefile' . "\n";
+	foreach my $prg (split /\s+/, $1)
+	{
+		my $proj = $solution->AddProject($prg, 'exe', 'bin');
+		$proj->AddFile("src/interfaces/libpq/test/$prg.c"); # implicit source file
+		$proj->AddIncludeDir('src/interfaces/libpq');
+		# XXX: pipeline needs pgcommon and ws2, but uri-regress doesn't
+		$proj->AddReference($libpq, $libpgport, $libpgcommon);
+		$proj->AddLibrary('ws2_32.lib');
+	}
+
 	$mf = Project::read_file('src/bin/scripts/Makefile');
 	$mf =~ s{\\\r?\n}{}g;
 	$mf =~ m{PROGRAMS\s*=\s*(.*)$}m

  28. Re: convert libpq uri-regress tests to tap test

    Andrew Dunstan <andrew@dunslane.net> — 2022-04-17T00:30:28Z

    On 2022-04-16 Sa 10:44, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
>> Pushed.  Attached is the remainder, 0003, the move of libpq_pipeline to
>> src/interfaces/libpq that I'm not planning to push for now.
> I saw that Andrew just pushed something to start building this under MSVC.
>
> In case it's of any interest, I had done this differently a while back.
> This probably doesn't apply except on top of some other patches, but you get
> the idea.
>

I think what I have committed should be quite adequate for now. Once we
get to building with meson a lot of this ugliness should go away.


cheers


andrew

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

  29. Re: convert libpq uri-regress tests to tap test

    Justin Pryzby <pryzby@telsasoft.com> — 2022-05-29T15:18:50Z

    On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
> 
> Pushed.

If I'm not wrong, this isn't being run by check-world.

commit 4dc465207517c4b69a1f2b657a8ad0700c08e34c
Author: Justin Pryzby <pryzbyj@telsasoft.com>
Date:   Sat May 28 22:32:58 2022 -0500

    libpq tests were not being run
    
    See also:
    ac25173cdbc40b310a7e72d9557c45a699f1f7b3
    6b04abdfc5e0653542ac5d586e639185a8c61a39

diff --git a/GNUmakefile.in b/GNUmakefile.in
index 2352fc1171a..cb613086c7c 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -68,10 +68,10 @@ check check-tests installcheck installcheck-parallel installcheck-tests: CHECKPR
 check check-tests installcheck installcheck-parallel installcheck-tests: submake-generated-headers
 	$(MAKE) -C src/test/regress $@
 
-$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib src/bin,check)
-$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg contrib src/bin)
+$(call recurse,check-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,check)
+$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin)
 
-$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib src/bin,installcheck)
+$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,installcheck)
 $(call recurse,install-tests,src/test/regress,install-tests)
 
 GNUmakefile: GNUmakefile.in $(top_builddir)/config.status

  30. Re: convert libpq uri-regress tests to tap test

    Michael Paquier <michael@paquier.xyz> — 2022-05-31T04:58:25Z

    On Sun, May 29, 2022 at 10:18:50AM -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
> > 
> > Pushed.
> 
> If I'm not wrong, this isn't being run by check-world.

You are right.

> -$(call recurse,check-world,src/test src/pl src/interfaces/ecpg contrib src/bin,check)
> -$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg contrib src/bin)
> +$(call recurse,check-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,check)
> +$(call recurse,checkprep,  src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin)
>  
> -$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg contrib src/bin,installcheck)
> +$(call recurse,installcheck-world,src/test src/pl src/interfaces/ecpg src/interfaces/libpq contrib src/bin,installcheck)
>  $(call recurse,install-tests,src/test/regress,install-tests)

Why don't you just use src/interfaces/ instead of adding a direct
path to libpq?
--
Michael

  31. Re: convert libpq uri-regress tests to tap test

    Michael Paquier <michael@paquier.xyz> — 2022-06-01T04:59:06Z

    On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
> Why don't you just use src/interfaces/ instead of adding a direct
> path to libpq?

So, this leads to something like the attached.  Does that sound fine
to you?
--
Michael

  32. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-06-02T16:47:22Z

    Hi,

On 2022-05-29 10:18:50 -0500, Justin Pryzby wrote:
> On Sat, Feb 26, 2022 at 05:46:26PM -0800, Andres Freund wrote:
> > On 2022-02-25 17:52:29 -0800, Andres Freund wrote:
> > > I'd like to commit 0001 and 0002 soon, unless somebody sees a reason not to?
> > 
> > Pushed.
> 
> If I'm not wrong, this isn't being run by check-world.

Oops, yes. Thanks for catching!

  33. Re: convert libpq uri-regress tests to tap test

    Andres Freund <andres@anarazel.de> — 2022-06-02T16:48:25Z

    Hi,

On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
> On Tue, May 31, 2022 at 01:58:25PM +0900, Michael Paquier wrote:
> > Why don't you just use src/interfaces/ instead of adding a direct
> > path to libpq?
> 
> So, this leads to something like the attached.  Does that sound fine
> to you?

That looks reasonable to me. Do you want to apply it or will you?

Regards,

Andres

  34. Re: convert libpq uri-regress tests to tap test

    Michael Paquier <michael@paquier.xyz> — 2022-06-03T00:43:28Z

    On Thu, Jun 02, 2022 at 09:48:25AM -0700, Andres Freund wrote:
> On 2022-06-01 13:59:06 +0900, Michael Paquier wrote:
>> So, this leads to something like the attached.  Does that sound fine
>> to you?
> 
> That looks reasonable to me. Do you want to apply it or will you?

Thanks for double-checking!  I should be able to take care of that
today.
--
Michael