| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Make copyObject work in C++ |
| Date: | 2026-01-14 15:59:55 |
| Message-ID: | fd1a4790-4fbc-43b4-a385-e3b98b9ed04d@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10.01.26 12:09, Jelte Fennema-Nio wrote:
> On Sat Jan 3, 2026 at 10:32 AM CET, Jelte Fennema-Nio wrote:
>> Attached is a patchset that does that. It required a few more fixes to
>> make the extension compile on MSVC too.
>
> Rebased after Peter merged the C++ improvements from the other thread.
I have a couple of comments on the sample extension module.
I think this module should have a runtime test, too. Otherwise you
don't know that you got the linkage correct, or whether this works at
all. It doesn't have to do much, like it could literally be a + b, and
it could evolve in the future to test hooks, _PG_init, etc.
Let's put a README file in the module's directory instead of putting the
explanation into the Makefile/meson.build.
I wonder if the module's build integration would work correctly in the
autoconf/makefile case if no C++ is available. AFAICT, it would fail to
build with g++ not found or similar.
AFAICT, the minimum changes to get a minimum test module to work are
- fix for "restrict", recently committed
- disable warning about zero-length arrays, seems trivial
- named designated initializers
I learned that named designated initializers in C++ are not allowed to
be specified out of order, so they are not a full equivalent to the C
syntax. This could be a problem for example if someone wanted in the
future to have something like
PG_MODULE_MAGIC_EXT(.threads_supported = true)
(while not specifying the leading .name and .version fields).
I think for now the easiest fix would be to just not use the named
initializers in the definition of PG_MODULE_MAGIC_DATA. Then we don't
need to require C++20 and have that additional code. In the future, we
might need a different solution more suitable for C++.
The use of -std=c++11 for CI is a valid idea; I have often wanted that
for C as well. But conversely we also want to allow testing optional
extension and future C standard features. So we need a comprehensive
solution there that covers both ends and both languages. Let's leave
that out for now and think about it separately.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Geier | 2026-01-14 16:02:35 | Re: Performance issues with parallelism and LIMIT |
| Previous Message | Sami Imseih | 2026-01-14 15:56:21 | Re: Cleaning up PREPARE query strings? |