Re: C testing for Postgres - Mailing list pgsql-hackers

From Adam Berlin
Subject Re: C testing for Postgres
Date
Msg-id CALGDgcScso6qjVb3Qo_2XZF2zBoOrZXy76m1WV90O27hwcZ7Hw@mail.gmail.com
Whole thread Raw
In response to Re: C testing for Postgres  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: C testing for Postgres
Re: C testing for Postgres
Re: C testing for Postgres
List pgsql-hackers
Here are my takeaways from the previous discussions:

* there *is* interest in testing
* we shouldn't take it too far
* there are already tests being written under `src/test/modules`, but without a consistent way of describing expectations and displaying results
* no tool was chosen

If we were to use this tool, would the community want to vendor the framework in the Postgres repository, or keep it in a separate repository that produces a versioned shared library?

On Fri, Jun 28, 2019 at 5:57 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> On Fri, Jun 28, 2019 at 11:38 AM Adam Berlin <aberlin@pivotal.io> wrote:
>
> During the unconference at PGCon in Ottawa, I asked about writing C-based
> tests for Postgres. There was interest in trying a tool and also some
> hesitation to depend on a third-party library. So, I wrote a tool that I'd
> like to contribute to Postgres. I’ve been calling it cexpect [1].

Cool, thanks!

> Rather than post a patch, I'd rather start a conversation first. I'm guessing
> there are some improvements that we'd want to make (for example: the
> Makefile) before commiting a patch. Let's iterate on improvements before
> creating a formal patch.

Just to mention, there were similar discussions already in the past ([1], [2]),
with some concerns being raised, but looks like without any visible results.

[1]: https://www.postgresql.org/message-id/flat/CAEepm%3D2heu%2B5zwB65jWap3XY-UP6PpJZiKLQRSV2UQH9BmVRXQ%40mail.gmail.com
[2]: https://www.postgresql.org/message-id/flat/Pine.LNX.4.58.0410111044030.14840%40linuxworld.com.au

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Conflict handling for COPY FROM
Next
From: Julien Rouhaud
Date:
Subject: Re: Avoid full GIN index scan when possible