From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Subject: Re: convert libpq uri-regress tests to tap test
In-reply-to: <ffe496e6-11ba-6f60-1621-90a600335cec@enterprisedb.com>
References: <20220223203031.ezrd73ohvjgfksow@alap3.anarazel.de> <ffe496e6-11ba-6f60-1621-90a600335cec@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Wed, 23 Feb 2022 23:53:17 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1261837.1645657117.1@sss.pgh.pa.us>
Date: Wed, 23 Feb 2022 17:58:37 -0500
Message-ID: <1261838.1645657117@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1261838.1645657117%40sss.pgh.pa.us>
Precedence: bulk

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