Horton

Re: Potential ABI breakage in upcoming minor releases

David E. Wheeler <david@justatheory.com>

View thread
From: "David E. Wheeler" <david@justatheory.com>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Marco Slot <marco.slot@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Christoph Berg <myon@debian.org>, Pavan Deolasee <pavan.deolasee@gmail.com>
Date: 2024-12-01T16:13:21Z
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 →

  1. Undo unintentional ABI break in struct ResultRelInfo.

  2. For inplace update durability, make heap_update() callers wait.

  3. Fix btmarkpos/btrestrpos array key wraparound bug.

  4. Fix calculation of which GENERATED columns need to be updated.

On Nov 29, 2024, at 15:39, Noah Misch <noah@leadboat.com> wrote:

> Then packagers who are taking the risk of not rebuilding every time will have
> 3 months to prepare, not the 3 days we're currently giving.  The point about
> "well-known extensions" is based on my practice of grepping PGXN.  That would
> not have found timescaledb.  Should we name PGXN explicitly, or should we be
> vague like that draft?  I'd be comfortable naming any number of repositories
> that make it equally easy to bulk-download the whole repository.

I’m wondering how we can help more projects make releases on PGXN, if for now other reason than to enable these kinds of checks without much additional effort. PGXN releases don’t require a ton of work, requiring just a META.json file in a zip file, and there are GitHub workflows to automate such releases. Anyone interested please hit me up directly for details. I even make pull requests like this one for pg_partman[1].

Best,

David


[1]: https://github.com/pgpartman/pg_partman/pull/671/files