Re: SSL Tests for sslinfo extension

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SSL Tests for sslinfo extension
Date: 2021-05-20 18:40:48
Message-ID: 09FAE16B-DDE3-4EB3-AEBA-7E31279AA173@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 19 May 2021, at 21:05, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 5/19/21 1:01 PM, Dagfinn Ilmari Mannsåker wrote:
>> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>
>>> In order to be able to test extensions with SSL connections, allow
>>> configure_test_server_for_ssl to create any extensions passed as
>>> comma separated list. Each extension is created in all the test
>>> databases which may or may not be useful.
>> Why the comma-separated string, rather than an array reference,
>> i.e. `extensions => [qw(foo bar baz)]`?

No real reason, I just haven't written Perl enough lately to "think in Perl".
Fixed in the attached.

>> Also, should it use `CREATE
>> EXTENSION .. CASCADE`, in case the specified extensions depend on
>> others?

Good point. Each extension will have to be in EXTRA_INSTALL as well of course,
but we should to CASCADE.

> Also, instead of one line per db there should be an inner loop over the
> db names.

Right, I was lazily using the same approach as for CREATE DATABASE but when the
list is used it two places it should be a proper list. Fixed in the attached.

--
Daniel Gustafsson https://vmware.com/

Attachment Content-Type Size
v2-0001-Extend-configure_test_server_for_ssl-to-add-exten.patch application/octet-stream 3.7 KB
v2-0002-Add-tests-for-sslinfo.patch application/octet-stream 5.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-05-20 18:57:40 Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS
Previous Message Pavel Stehule 2021-05-20 18:39:33 Re: CALL versus procedures with output-only arguments