From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Convert sepgsql tests to TAP |
Date: | 2024-07-24 14:31:32 |
Message-ID: | eb578852-fe49-4366-bfae-440aa5ed88c1@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I took a quick look at the patch and I like that we standardize things a
bit. But one thing I am not a fan of are all the use of sed and awk in
the Perl script. I would prefer if that logic happened all in Perl,
especially since we have some of it in Perl (e.g. chomp). Also I wonder
if we should not use IPC::Run to do the tests since we already depend on
it for the other TAP tests.
I have not yet set up an VM with selinux to try the patch out for real
but will do so later.
On 5/13/24 8:16 AM, Peter Eisentraut wrote:
> - Do we want to keep the old way to run the test? I don't know all the
> testing scenarios that people might be interested in, but of course it
> would also be good to cut down on the duplication in the test files.
I cannot see why. Having two ways to run the tests seems only like a bad
thing to me.
> - If you go through the pre-test checks in contrib/sepgsql/test_sepgsql,
> I have converted most of these checks to the Perl script. Some of the
> checks are obsolete, because they check whether the database has been
> correctly initialized, which is now done by the TAP script anyway. One
> check that I wasn't sure about is the
>
> # 'psql' command must be executable from test domain
>
> The old test was checking the installation tree, which I guess could be
> set up in random ways. But do we need this kind of check if we are
> using a temporary installation?
Yeah, that does not seem necessary.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Marat Bukharov | 2024-07-24 14:42:11 | Re: [PATCH] Add min/max aggregate functions to BYTEA |
Previous Message | Stan Hu | 2024-07-24 14:30:30 | pg_upgrade adds unexpected pg_constraint entries to pg_depend |