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 по дате отправления: