Thread: Support "make check" for PGXS extensions
This is a quick follow-up to the extension_control_path patch. With this little additional patch, you can now run "make check" in PGXS-using extensions (instead of having to do make install; make installcheck with a running instance). I think this would be very convenient for extension development. The patch is still rough, probably needs a bit of work to do proper escaping, quoting, further testing, and it will probably break if you use a different source tree layout. Maybe with a bit of help we can get this robust enough. Or otherwise, it can at least serve as inspiration for what you can implement yourself in your extension's makefile.
Attachment
On Mar 20, 2025, at 09:06, Peter Eisentraut <peter@eisentraut.org> wrote: > > This is a quick follow-up to the extension_control_path patch. With this little additional patch, you can now run "makecheck" in PGXS-using extensions (instead of having to do make install; make installcheck with a running instance). I think this would be very convenient for extension development. I LOVE this idea! But one thing to keep in mind is that not all files are in CURDIR. Might make sense to use `dirname` onall the entires in DATA and MODULES to figure out what to put in the search paths. I usually have my C files in `src` andSQL files in `sql`, and wrote the PGXN tutorial[1] back in 2012 with that pattern (for better or worse). A simple exampleis the envvar extension[2]: DATA = $(wildcard sql/*.sql) MODULES = $(patsubst %.c,%,$(wildcard src/*.c)) Best, David [1]: https://manager.pgxn.org/howto#neworder [2]: https://github.com/theory/pg-envvar/blob/main/Makefile
Attachment
On 3/20/25 13:20, David E. Wheeler wrote: > On Mar 20, 2025, at 09:06, Peter Eisentraut <peter@eisentraut.org> wrote: >> >> This is a quick follow-up to the extension_control_path patch. >> With this little additional patch, you can now run "make check" in >> PGXS-using extensions (instead of having to do make install; make >> installcheck with a running instance). I think this would be very >> convenient for extension development. > I LOVE this idea! +many -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
On 2025-03-20 Th 9:06 AM, Peter Eisentraut wrote: > This is a quick follow-up to the extension_control_path patch. With > this little additional patch, you can now run "make check" in > PGXS-using extensions (instead of having to do make install; make > installcheck with a running instance). I think this would be very > convenient for extension development. > > The patch is still rough, probably needs a bit of work to do proper > escaping, quoting, further testing, and it will probably break if you > use a different source tree layout. Maybe with a bit of help we can > get this robust enough. Or otherwise, it can at least serve as > inspiration for what you can implement yourself in your extension's > makefile. No support for TAP tests, AFAICT. I guess this is a first step, but TAP support would be nice. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On Thu, Mar 20, 2025 at 1:57 PM Joe Conway <mail@joeconway.com> wrote: > > I LOVE this idea! > +many Same here. But I also agree with Andrew that it would be fantastic if TAP tests could be made to work, too. Yet, anything beats nothing! -- Robert Haas EDB: http://www.enterprisedb.com
On 20.03.25 18:20, David E. Wheeler wrote: > On Mar 20, 2025, at 09:06, Peter Eisentraut <peter@eisentraut.org> wrote: >> >> This is a quick follow-up to the extension_control_path patch. With this little additional patch, you can now run "makecheck" in PGXS-using extensions (instead of having to do make install; make installcheck with a running instance). I think this would be very convenient for extension development. > > I LOVE this idea! But one thing to keep in mind is that not all files are in CURDIR. Might make sense to use `dirname`on all the entires in DATA and MODULES to figure out what to put in the search paths. I usually have my C filesin `src` and SQL files in `sql`, and wrote the PGXN tutorial[1] back in 2012 with that pattern (for better or worse).A simple example is the envvar extension[2]: > > DATA = $(wildcard sql/*.sql) > MODULES = $(patsubst %.c,%,$(wildcard src/*.c)) Interesting. I think to support that, we would need to do a temp install kind of thing of the extension, and then point the path settings into that temp install directory. Which is probably more sensible anyway.
On Mar 27, 2025, at 12:21, Peter Eisentraut <peter@eisentraut.org> wrote: > Interesting. I think to support that, we would need to do a temp install kind of thing of the extension, and then pointthe path settings into that temp install directory. Which is probably more sensible anyway. If it runs against a temporary cluster anyway, I think that makes perfect sense. D