Message-ID: <f51d3f80-3b9d-7ba4-fbd7-06ce63ea15f1@enterprisedb.com>
Date: Thu, 24 Feb 2022 13:31:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.0
Subject: Re: convert libpq uri-regress tests to tap test
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
References: <20220223203031.ezrd73ohvjgfksow@alap3.anarazel.de>
 <ffe496e6-11ba-6f60-1621-90a600335cec@enterprisedb.com>
 <1261838.1645657117@sss.pgh.pa.us>
 <4f4c04c2-f23c-6668-1b24-224fc6478bfd@enterprisedb.com>
 <1276236.1645667561@sss.pgh.pa.us>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <1276236.1645667561@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/f51d3f80-3b9d-7ba4-fbd7-06ce63ea15f1%40enterprisedb.com>
Precedence: bulk

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.