From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
cc: Andrew Dunstan <andrew@dunslane.net>, Andres Freund <andres@anarazel.de>,
        Michael Paquier <michael@paquier.xyz>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        Jaime Casanova <jcasanov@systemguards.com.ec>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: SQL-standard function body
In-reply-to: <20210408111936.bbrjonwadodhaswf@nol>
References: <01c65ea6-e5bf-22f4-cacc-6d0f6853a965@2ndquadrant.com>
 <1646498.1617826937@sss.pgh.pa.us> <YG54YggzyPrTFE+e@paquier.xyz>
 <1819824.1617858962@sss.pgh.pa.us>
 <20210408052759.7bmyawm4djnrux6y@alap3.anarazel.de>
 <20210408054626.gyz3al2j5r5kzhrt@nol> <1821917.1617861925@sss.pgh.pa.us>
 <20210408063320.eciql3ay52ge5flz@alap3.anarazel.de>
 <20210408064036.fwf2o6stviilbocf@nol> <1825656.1617865082@sss.pgh.pa.us>
 <20210408111936.bbrjonwadodhaswf@nol>
Comments: In-reply-to Julien Rouhaud <rjuju123@gmail.com>
	message dated "Thu, 08 Apr 2021 19:19:36 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1884373.1617898865.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Apr 2021 12:21:05 -0400
Message-ID: <1884374.1617898865@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1884374.1617898865%40sss.pgh.pa.us>
Precedence: bulk

Julien Rouhaud <rjuju123@gmail.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 coverage.postgresql.org.

> Is there any chance that coverage.postgresql.org isn't backed by the bui=
ldfarm
> 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 =3D 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