Re: test_json_parser/002_inline is kind of slow - Mailing list pgsql-hackers

From Robert Haas
Subject Re: test_json_parser/002_inline is kind of slow
Date
Msg-id CA+TgmoYr-NOuu31VLL27grD_iPY91yoS3Z5eAUQ9j1wscN64SQ@mail.gmail.com
Whole thread Raw
In response to Re: test_json_parser/002_inline is kind of slow  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
On Fri, Sep 26, 2025 at 11:50 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> On Fri, Sep 26, 2025 at 8:38 AM Andres Freund <andres@anarazel.de> wrote:
> > You can just support running multiple tests with one run of the executable,
> > e.g. by splitting the input / output on null bytes.
>
> Yeah, but that doubles down on the bad unit test architecture... and I
> don't think anyone would want to touch that code after I wrote it. But
> it could be a quicker fix, especially if people are nervous about
> moving to C+TAP.

I'm not bothered by C+TAP. The thing that I'm not crazy about with
Python+TAP is that I fear that eventually everyone will have to know
both enough Perl and enough Python to be able to write and maintain
TAP tests, and I'm not that keen about that. I realize there may be no
real alternative given the fading of Perl, but the requirements for
people to hack on PostgreSQL are already quite high and I'd like to do
whatever we reasonably can to avoid further elevating them. Replacing
Perl with Python would probably lower the requirement overall even
though it would be a painful adjustment for me personally, but the
long-to-indefinite period of coexistence is a bummer. But none of that
argument applies to having C produce TAP output. Everyone who wants to
hack on PostgreSQL needs to know C anyway.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] GROUP BY ALL
Next
From: David Christensen
Date:
Subject: Re: [PATCH] GROUP BY ALL