Re: test_json_parser/002_inline is kind of slow

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: test_json_parser/002_inline is kind of slow
Дата
Msg-id gmcaxp5u2yy6ycgosaooji2zuhpp6mg2mvw5ra7ihhrade5yoe@2uuwpb4364az
обсуждение исходный текст
Ответ на Re: test_json_parser/002_inline is kind of slow  (Jacob Champion <jacob.champion@enterprisedb.com>)
Ответы Re: test_json_parser/002_inline is kind of slow
Список 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 по дате отправления: