From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: convert libpq uri-regress tests to tap test |
Date: | 2022-02-24 12:31:40 |
Message-ID: | f51d3f80-3b9d-7ba4-fbd7-06ce63ea15f1@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24.02.22 02:52, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>> On 23.02.22 23:58, Tom Lane wrote:
>>> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-02-24 12:34:42 | Re: Proposal: Support custom authentication methods using hooks |
Previous Message | Peter Eisentraut | 2022-02-24 12:23:55 | Re: Design of pg_stat_subscription_workers vs pgstats |