Re: Convert sepgsql tests to TAP - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Convert sepgsql tests to TAP
Date
Msg-id c9a83e60-ef82-4fe3-b827-f6972bb6fe24@joeconway.com
Whole thread Raw
In response to Convert sepgsql tests to TAP  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Convert sepgsql tests to TAP
List pgsql-hackers
On 1/24/25 09:00, Andrew Dunstan wrote:
> 
> On 2025-01-24 Fr 7:25 AM, Peter Eisentraut wrote:
>> On 27.08.24 10:12, Peter Eisentraut wrote:
>>> Here is a new patch version.
>>>
>>> I simplified the uses of sed and awk inside the Perl script.  I also 
>>> fixed "make installcheck".  I noticed that meson installs sepgsql.sql 
>>> into the wrong directory, so that's fixed also. (Many of the 
>>> complications in this patch set are because sepgsql is not an 
>>> extension but a loose SQL script, of which it is now the only one.  
>>> Maybe something to address separately.)
>>>
>>> I did end up deciding to keep the old test_sepgsql script, because it 
>>> does have the documented purpose of testing existing installations.  
>>> I did change it so that it calls pg_regress directly, without going 
>>> via make, so that the dependency on make is removed.
>>
>> This has been committed.  And I understand there is a buildfarm client 
>> update available for the affected buildfarm members.
> 
> This should only be rhinoceros. Joe can pull this fix:
> https://github.com/PGBuildFarm/client-code/commit/60b72787036090c6bf829f5cef2b0b3e60f2a2db
> (or just copy the whole file from
> https://raw.githubusercontent.com/PGBuildFarm/client-code/refs/heads/main/PGBuild/Modules/TestSepgsql.pm)


Out of curiosity, what should have changed? I have so far done nothing 
to rhino, yet it continues to return OK even after Peter's change...

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_createsubscriber TAP test wrapping makes command options hard to read.
Next
From: Tom Lane
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql