Re: Potential ABI breakage in upcoming minor releases

Aleksander Alekseev <aleksander@timescale.com>

From: Aleksander Alekseev <aleksander@timescale.com>

To: pgsql-hackers <pgsql-hackers@postgresql.org>

Cc: Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter@eisentraut.org>, Pavan Deolasee <pavan.deolasee@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>

Date: 2024-11-14T16:43:53Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Undo unintentional ABI break in struct ResultRelInfo.
- ee33d58471de 16.6 landed
- 6bfacd368bb4 17.2 landed
- 17db248f318f 15.10 landed
- 099e711b77b8 14.15 landed
For inplace update durability, make heap_update() callers wait.
- 51ff46de29f6 16.5 cited
Fix btmarkpos/btrestrpos array key wraparound bug.
- 3fa81b62e09b 16.1 cited
Fix calculation of which GENERATED columns need to be updated.
- 8cd190e13a22 14.7 cited

Hi,

> Right.  makeNode(), palloc(sizeof), and stack allocation have that problem.
> Allocation wrappers like CreateExecutorState() avoid the problem.  More
> generally, structs allocated in non-extension code are fine.

Perhaps we should consider adding an API like makeResultRelInfo() and
others, one per node. It's going to be boilerplate for sure, but
considering the fact that we already generate some code I don't really
see drawbacks.

-- 
Best regards,
Aleksander Alekseev