Thread

  1. Support "make check" for PGXS extensions

    Peter Eisentraut <peter@eisentraut.org> — 2025-03-20T13:06:20Z

    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.
    
  2. Re: Support "make check" for PGXS extensions

    David E. Wheeler <david@justatheory.com> — 2025-03-20T17:20:30Z

    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))
    
    Best,
    
    David
    
    [1]: https://manager.pgxn.org/howto#neworder
    [2]: https://github.com/theory/pg-envvar/blob/main/Makefile
    
    
  3. Re: Support "make check" for PGXS extensions

    Joe Conway <mail@joeconway.com> — 2025-03-20T17:57:23Z

    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
    
    
    
    
  4. Re: Support "make check" for PGXS extensions

    Andrew Dunstan <andrew@dunslane.net> — 2025-03-20T21:31:49Z

    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
    
    
    
    
    
  5. Re: Support "make check" for PGXS extensions

    Robert Haas <robertmhaas@gmail.com> — 2025-03-20T23:55:34Z

    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
    
    
    
    
  6. Re: Support "make check" for PGXS extensions

    Peter Eisentraut <peter@eisentraut.org> — 2025-03-27T16:21:47Z

    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.
    
    
    
    
    
  7. Re: Support "make check" for PGXS extensions

    David E. Wheeler <david@justatheory.com> — 2025-03-27T17:23:02Z

    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