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.
Attachments:
v0-0001-WIP-Support-make-check-for-PGXS-extensions.patchtext/plain; charset=UTF-8; name=v0-0001-WIP-Support-make-check-for-PGXS-extensions.patchDownload+8-3
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! 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 files in `src` and SQL files in `sql`, and wrote the PGXN tutorial[1]https://manager.pgxn.org/howto#neworder back in 2012 with that pattern (for better or worse). A simple example is the envvar extension[2]https://github.com/theory/pg-envvar/blob/main/Makefile:
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
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 "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! 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 files in `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 point the 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