Re: Small TAP improvements

On 2022-06-14 Tu 19:13, Michael Paquier wrote:
> On Tue, Jun 14, 2022 at 12:20:56PM -0400, Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> The second changes the new GUCs TAP test to check against the installed
>>> postgresql.conf.sample rather than the one in the original source
>>> location. There are probably arguments both ways, but if we ever decided
>>> to postprocess the file before installation, this would do the right thing.
>> Seems like a good idea, especially since it also makes the test code
>> shorter and more robust(-looking).
> It seems to me that you did not look at the git history very closely.
> The first version of 003_check_guc.pl did exactly what 0002 is
> proposing to do, see b0a55f4. That's also why config_data() has been
> introduced in the first place. This original logic has been reverted
> once shortly after, as of 52377bb, per a complain by Christoph Berg
> because this broke some of the assumptions the custom patches of
> Debian relied on:
> https://www.postgresql.org/message-id/YgYw25OXV5men8Fj@msg.df7cb.de

Quite right, I missed that. Still, it now seems to be moot, given what
Christoph said at the bottom of the thread. If I'd seen the thread I
would probably have been inclined to say that is Debian can patch
pg_config they can also patch the test :-)

>
> And it was also pointed out that we'd better use the version in the
> source tree rather than a logic that depends on finding the path from
> the output of pg_config with an installation tree assumed to exist
> (there should be one for installcheck anyway), as of:
> https://www.postgresql.org/message-id/2023925.1644591595@sss.pgh.pa.us
>
> If the change of 0002 is applied, we will just loop back to the
> original issue with Debian. So I am adding Christoph in CC, as he has
> also mentioned that the patch applied to PG for Debian that
> manipulates the installation paths has been removed, but I may be
> wrong in assuming that it is the case.

Honestly, I don't care all that much. I noticed these issues when
dealing with something for EDB that turned out not to be related to
these things. I can see arguments both ways on this one.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com