| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Improve code coverage of network address functions |
| Date: | 2025-01-20 20:27:21 |
| Message-ID: | 3126173.1737404841@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
> On Mon, Jan 20, 2025 at 11:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Maybe we could add this to the existing src/test/ssl/ tests,
>> which already deal with that hazard?
> That seems okay in the short term. (But it certainly highlights our
> lack of a "PG_TEST_EXTRA=loopback-is-fine" mode...)
Part of my thought here is that these functions are not worth their
very own TAP test, with all the overhead that implies of firing up
a new database instance. So I was looking for something we could
fold them into. I agree the SSL tests are focused on something
else, but still...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2025-01-20 20:40:34 | Re: Re: proposal: schema variables |
| Previous Message | Jacob Champion | 2025-01-20 20:20:05 | Re: [PATCH] Improve code coverage of network address functions |