Re: test_json_parser/002_inline is kind of slow

On Fri, Sep 26, 2025 at 11:50 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> On Fri, Sep 26, 2025 at 8:38 AM Andres Freund <andres(at)anarazel(dot)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