From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andrew Kane <andrew(at)ankane(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Restore support for USE_ASSERT_CHECKING in extensions only |
Date: | 2025-01-10 23:17:23 |
Message-ID: | CAApHDvogqCoP_aw3_6CySi8eOgD0BPV3+1pBKtGZUGT=EHj6LA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 11 Jan 2025 at 11:27, Andrew Kane <andrew(at)ankane(dot)org> wrote:
> Prior to 6f3820f, extensions could be compiled with -DUSE_ASSERT_CHECKING whether or not the Postgres installation was configured with --enable-cassert (to enable at least some assertion checking). However, after 6f3820f, linking fails with `undefined symbol: verify_compact_attribute`. I'm not sure if this use case is officially supported, but it has been helpful for developing pgvector.
>
> The attached patch fixes it, but there may be a better way to do this.
hmm, I didn't think of that scenario. I think since
verify_compact_attribute() does nothing when USE_ASSERT_CHECKING isn't
defined that we might as well define a ((void) 0) macro to avoid the
undefined symbol error. That'll avoid the useless call in your debug
builds.
I looked around for inspiration and that's what pgstat_assert_is_up()
does. Most of the other examples are static functions.
David
Attachment | Content-Type | Size |
---|---|---|
fix_verify_compact_attribute.patch | application/octet-stream | 513 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2025-01-10 23:25:48 | Re: Proposal: add new API to stringinfo |
Previous Message | Abhishek Chanda | 2025-01-10 23:16:44 | Re: Adding support for SSLKEYLOGFILE in the frontend |