On Tue, Jun 14, 2022 at 12:20:56PM -0400, Tom Lane wrote: > Andrew Dunstan <and...@dunslane.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/ygyw25oxv5men...@msg.df7cb.de 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.1644591...@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. -- Michael
signature.asc
Description: PGP signature
