Re: Convert sepgsql tests to TAP

On 24.07.24 23:03, Andreas Karlsson wrote:
> On 7/24/24 10:35 PM, Tom Lane wrote:
>> Andreas Karlsson <andreas(at)proxel(dot)se> writes:
>>> 1) As I said earlier I think we should remove the old code.
>>
>> I agree that carrying two versions of the test doesn't seem great.
>> However, a large part of the purpose of test_sepgsql is to help
>> people debug their sepgsql setup, which is why it goes to great
>> lengths to print helpful error messages.  I'm worried that making
>> it into a TAP test will degrade the usefulness of that, simply
>> because the TAP infrastructure is pretty damn unfriendly when it
>> comes to figuring out why a test failed.  You have to know where
>> to even look for the test logfile, and then you have to ignore
>> a bunch of useless-to-you chatter.  I'm not sure if there is much
>> we can do to improve that.  (Although if we could, it would
>> yield benefits across the whole tree.)
>
> For me personally the output from when running it with meson was good
> enough while the output when running with autotools was usable but
> annoying to work with. Meson's integration with TAP is pretty good. But
> with that said I am a power user and developer used to both meson and
> autotools. Unclear what skill we should expect from the target audience
> of test_sepgsql.

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.

The documentation is also updated a little bit, but I kept it to a
minimum, because I'm not really sure how up to date the existing
documentation was. It lists several steps in the test procedure that I
didn't need to do. Someone who knows more about the whole picture would
need to look at that in more detail.