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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, Mankirat Singh <mankiratsingh1315(at)gmail(dot)com>
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date: 2025-10-29 23:52:11
Message-ID: 2923669.1761781931@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David E. Wheeler" <david(at)justatheory(dot)com> writes:
> On Oct 29, 2025, at 17:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... I still do not like having any
>> policy decisions about which branches to check hard-wired into the
>> buildfarm client.

> Well that’s pretty easily addressed by adding a configuration for it. Maybe a regex to match branches, defaulting to its current value[0], `/_STABLE$/`.

I'm asking to remove complexity, not add more. The buildfarm client
should not be checking either branch names or git tags to control
this, when we have a perfectly good convention about the existence
of .abi-compliance-history to control it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-29 23:55:12 Re: Fix bogus use of "long" in aset.c
Previous Message Michael Paquier 2025-10-29 23:40:54 Re: Fix bogus use of "long" in aset.c