Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Дата
Msg-id 21ABA09A-3E03-4DDF-BE9D-A916EFD8ABE0@justatheory.com
обсуждение исходный текст
Ответ на Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Список pgsql-hackers
On Oct 30, 2025, at 09:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Trouble is, you then need an arbitrary client-made choice about which
> commit to run the ABI check against.

It’s currently coded to use the most recent tag or, if there is none in the branch, the branch root.

> If that code does something we
> realize we don't want, we're back up against the problem of moving the
> buildfarm configuration to fix it.  I'd rather the decision be opt-in.

Fair. Just means that if no one adds a history file to a branch that branch will never be tested and there’s no
automatedway to realize it. 

> (Also, the only rules I heard proposed for such client-driven choices
> involved git tags.  I already explained why I don't want that: git
> tags are hard to modify and subject to too many other constraints.)

Yeah, it just went with the most recent tag to keep it simple, no other metadata.

D


Вложения

В списке pgsql-hackers по дате отправления: