| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Differential code coverage between 16 and HEAD |
| Date: | 2024-04-16 00:05:43 |
| Message-ID: | 20240416000543.zkgdfboc44nn5zo6@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2024-04-15 16:53:48 -0700, Jeff Davis wrote:
> On Sun, 2024-04-14 at 15:33 -0700, Andres Freund wrote:
> > - Coverage for some of the new unicode code is pretty poor:
> >
> > https://anarazel.de/postgres/cov/16-vs-HEAD-2024-04-14/src/common/unicode_category.c.gcov.html#L122
>
> Thank you for looking. Those functions are tested by category_test.c
> which is run with the 'update-unicode' target.
Testing just during update-unicode doesn't strike me as a great - that way
portability issues wouldn't be found. And if it were tested that way, coverage
would understand it too. I can just include update-unicode when running
coverage, but that doesn't seem great.
Can't we test this as part of the normal testsuite?
I don't at all like that the tests depend on downloading new unicode
data. What if there was an update but I just want to test the current state?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-04-16 00:10:19 | Re: Stability of queryid in minor versions |
| Previous Message | Justin Pryzby | 2024-04-16 00:02:03 | Re: pg17 issues with not-null contraints |