> On 17 May 2024, at 09:58, Daniel Gustafsson wrote:
>
>> On 17 May 2024, at 07:57, Peter Eisentraut wrote:
>>
>> On 16.05.24 23:27, Daniel Gustafsson wrote:
On 16 May 2024, at 11:43, Peter Eisentraut wrote:
You might want to run your patch through pgperltidy. The result doesn't
>>
> On 17 May 2024, at 07:57, Peter Eisentraut wrote:
>
> On 16.05.24 23:27, Daniel Gustafsson wrote:
>>> On 16 May 2024, at 11:43, Peter Eisentraut wrote:
>>> You might want to run your patch through pgperltidy. The result doesn't
>>> look bad, but a bit different than what you had crafted.
>>
On 16.05.24 23:27, Daniel Gustafsson wrote:
On 16 May 2024, at 11:43, Peter Eisentraut wrote:
You might want to run your patch through pgperltidy. The result doesn't look
bad, but a bit different than what you had crafted.
Ugh, I thought I had but clearly had forgotten. Fixed now.
appen
> On 16 May 2024, at 11:43, Peter Eisentraut wrote:
> You might want to run your patch through pgperltidy. The result doesn't look
> bad, but a bit different than what you had crafted.
Ugh, I thought I had but clearly had forgotten. Fixed now.
> append_conf() opens and closes the file for eac
On 16.05.24 09:24, Daniel Gustafsson wrote:
When writing a new SSL test for another patch it struck me that the SSL tests
are doing configuration management without using the test framework API's. The
attached patches cleans this up, no testcases are altered as part of this.
0001 makes the test
When writing a new SSL test for another patch it struck me that the SSL tests
are doing configuration management without using the test framework API's. The
attached patches cleans this up, no testcases are altered as part of this.
0001 makes the test for PG_TEST_EXTRA a top-level if statement no
