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

From Andres Freund
Subject Re: test_json_parser/002_inline is kind of slow
Date
Msg-id gmcaxp5u2yy6ycgosaooji2zuhpp6mg2mvw5ra7ihhrade5yoe@2uuwpb4364az
Whole thread Raw
In response to Re: test_json_parser/002_inline is kind of slow  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: test_json_parser/002_inline is kind of slow
List pgsql-hackers
Hi,

On 2025-09-26 08:49:51 -0700, Jacob Champion 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.

I don't really understand - what I'm proposing should just be a few lines?
Splitting on some separator is hardly hard to understand code.


> But it could be a quicker fix, especially if people are nervous about moving
> to C+TAP.

I don't have a problem with that in general, although I suspect we'd want some
fe_utils (or such) helper for handling the tap bits centrally. I'm not
convinced that it's the right thing to pursue here, and I'm wholly unconvinced
by the reasoning.

ISTM that the test vectors and the patttern matching on them in 002_inline.pl
makes much more sense in a scripting language than in a C file.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: [PATCH] GROUP BY ALL
Next
From: Tom Lane
Date:
Subject: Re: test_json_parser/002_inline is kind of slow