Re: SQL-standard function body

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SQL-standard function body
Date: 2021-04-08 16:21:05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Thu, Apr 08, 2021 at 02:58:02AM -0400, Tom Lane wrote:
>> No, because if that were the explanation then we'd be getting no
>> buildfarm coverage at all for for pg_stat_statements. Which aside
>> from being awful contradicts the results at

> Is there any chance that isn't backed by the buildfarm
> client but a plain make check-world or something like that?

Hmm, I think you're right. Poking around in the log files from one
of my own buildfarm animals, there's no evidence that pg_stat_statements
is being tested at all. Needless to say, that's just horrid :-(

I see that contrib/test_decoding also sets NO_INSTALLCHECK = 1,
and the reason it gets tested is that the buildfarm script has
a special module for that. I guess we need to clone that module,
or maybe better, find a way to generalize it.

There are also some src/test/modules modules that set NO_INSTALLCHECK,
but apparently those do have coverage (modules-check is the step that
runs their SQL tests, and then the TAP tests if any get broken out
as separate buildfarm steps).

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2021-04-08 16:29:25 Re: VACUUM (DISABLE_PAGE_SKIPPING on)
Previous Message Alvaro Herrera 2021-04-08 16:19:16 Re: Autovacuum on partitioned table (autoanalyze)