MIME-Version: 1.0
References: <CAOYmi+moGFuBaaAHq=kixGk0YuOZan09Wn5O4WAzA-xLTEumaA@mail.gmail.com>
 <CA+TgmoY4DRMVEV7CVo1D8p==ExsN69W89rF7-Ax4V=M9HGWL7g@mail.gmail.com>
 <CA+TgmoZV8B35Mvx8DqHtJjHDQxscJhwOWzNWiPj+dsUhwaUfSg@mail.gmail.com>
 <2302192.1718380169@sss.pgh.pa.us> <CAOYmi+k214g1tgREvQkUcr=OCiVKyaTDu1ja+OGAygG1y=jhPQ@mail.gmail.com>
 <CAOYmi+nEqA2LmetcJKUDmctypPLLumkVwj3vQ3idYd8yAGza5Q@mail.gmail.com>
 <CAOYmi+kebAt6wSX7ee0c0kMzV7r0hp93bAt10V5a88yHHUKwog@mail.gmail.com>
 <CAOYmi+=CrBFBRX-foRRES2tx2wXBJJhbsJGjgFbWvPcmBJuK-Q@mail.gmail.com>
 <DDOUZE2TCU8O.89TN0AS4GLP7@jeltef.nl> <DE5BODEZ607Y.3LNII22O5N27O@jeltef.nl>
 <g4gdtfedwwdgu5sbcopjt3djtqk6p2q7n5nymp7ppapfwukoyd@ev2v4jtsbure>
 <CAOYmi+mV97+FC=ME0EZj+3LBFHZ3g_xGmTGA_3u+TwJ_pvpFWw@mail.gmail.com> <DFHQQ4VS43SU.25NN2Y5GDWANL@jeltef.nl>
In-Reply-To: <DFHQQ4VS43SU.25NN2Y5GDWANL@jeltef.nl>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Tue, 6 Jan 2026 17:01:03 -0800
Message-ID: <CAOYmi+ng-7j6JTzD5pe3AutHZ=LAJqVN1ZGNQwKAOfA2MYiBfg@mail.gmail.com>
Subject: Re: RFC: adding pytest as a supported test framework
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, 
	Robert Haas <robertmhaas@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>, 
	Peter Eisentraut <peter@eisentraut.org>, Nazir Bilal Yavuz <byavuz81@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2Bng-7j6JTzD5pe3AutHZ%3DLAJqVN1ZGNQwKAOfA2MYiBfg%40mail.gmail.com>
Precedence: bulk

On Tue, Jan 6, 2026 at 11:07=E2=80=AFAM Jelte Fennema-Nio <postgres@jeltef.=
nl> wrote:
> > That's fine by me, but I plan to focus on
> > things that need to get into PG19 before I focus on this, since
> > nothing is really blocked on it.
>
> Part of the reason why I've been trying to push this forward is that
> automated tests for the GoAway patch are definitely blocked on this. (The
> other reason is that I'd like to reduce the amount of perl I have to
> read/write.)

Ah, okay. To state publicly what I've already mentioned to you
off-list: I have absolutely no intention of going it alone on this. My
bar is enthusiastic buy-in from a number of maintainers (the price
paid for expanding the scope from "made-for-purpose protocol test
suite" to "eventual Test::Cluster replacement"), and no -1s. I expect
that to take a while.

It's perfectly okay if you'd like to tie the GoAway proposal to this,
but that seems like it's unlikely to result in short-term success. It
was in Drafts for a reason. The stated point of v2 was to "spark some
opinions and conversation", and I have no plans to fast-track this
patchset for 19.

> >> I think it'd be a seriously bad idea to start with no central infrastr=
ucture,
> >> we'd be force to duplicate that all over.
> >
> > Right, I just want central infra to be pulled out of the new tests
> > that need them rather than the other way around.
>
> I'm not sure how you expect that to work in practice.

Hopefully I'm just describing refactoring? Holding your nose,
open-coding it in a test even though you'd rather not, showcasing the
way you'd like to use it so we can discuss the style, and refactoring
it outwards and upwards in a later patch in the set, once you hit the
rule of three and there's a pattern of usage and an API that people
like. (This may have been what you're doing with v4 onwards, but again
I haven't been able to sit down with it.)

> I believe (and I
> think Andres too) that there's some infra that we already know we'll
> need for many tests, e.g. starting/stopping nodes, running queries,
> handling errors. [snip]

Sure -- I feel like I've already agreed with that upthread, ad
nauseam... along with my reasons why v2 hadn't tackled any of that
yet. I'd hoped to talk about the design questions I had in v2, but
it's OSS and no one is required to talk about things just because I
want them to. :D Your v3 rewrote it instead, and I haven't had time to
review v3 yet.

Writing code to start and stop a server and run SQL is a matter of
programming. Writing a test suite that newcomers can intuitively use,
and test interesting new things with, is a long-term collaboration. I
am much more interested in doing the latter, because we already have
the former, and personally I'm happy to build momentum slowly and wait
on a group of people who are in a good place to discuss it.

--Jacob