| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-25 20:06:12 |
| Message-ID: | 2h2n2gyw2f4ucicbl3drtdkjt2wzf6b2r4wqm7xwks6vpx5j7n@imymv4hkz5jz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-01-25 18:52:37 +0100, Jelte Fennema-Nio wrote:
> On Sun Jan 25, 2026 at 5:50 PM CET, Andres Freund wrote:
> > We were going for designated
> > initializers for a reason, namely that we expect more arguments to be added
> > over time and perhaps eventually also to remove some. And this will just lead
> > to that being harder because we have to worry about C++ extensions.
>
> Adding new arguments (aka fields) should cause no problems. Assuming
> we'd add them at the end of the Pg_magic_struct definition. Removing
> ones seems like even for C you'd need different PG_MODULE_MAGIC_EXT
> invocations depending on PG_VERSION_NUM. I don't see how using
> positional args would make that harder.
Named args make that easier in two ways: First, only extensions using the
to-be-removed option will fail. Second, removal of options reliably generates
errors, rather than bogusly use one field for another, just because the types
are compatible.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2026-01-25 20:32:34 | Re: ABI Compliance Checker GSoC Project |
| Previous Message | Mihail Nikalayeu | 2026-01-25 18:39:00 | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |