| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: test_json_parser/002_inline is kind of slow |
| Date: | 2025-09-26 16:01:20 |
| Message-ID: | gmcaxp5u2yy6ycgosaooji2zuhpp6mg2mvw5ra7ihhrade5yoe@2uuwpb4364az |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(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.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-09-26 16:01:45 | Re: test_json_parser/002_inline is kind of slow |
| Previous Message | David Christensen | 2025-09-26 15:59:26 | Re: [PATCH] GROUP BY ALL |