Re: test_json_parser/002_inline is kind of slow
От | Robert Haas |
---|---|
Тема | Re: test_json_parser/002_inline is kind of slow |
Дата | |
Msg-id | CA+TgmoYr-NOuu31VLL27grD_iPY91yoS3Z5eAUQ9j1wscN64SQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: test_json_parser/002_inline is kind of slow (Jacob Champion <jacob.champion@enterprisedb.com>) |
Список | pgsql-hackers |
On Fri, Sep 26, 2025 at 11:50 AM Jacob Champion <jacob.champion@enterprisedb.com> 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. 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
В списке pgsql-hackers по дате отправления: