Re: Development of ABI Compliance Checker for official PostgreSQL Repo

On Wed, 21 May 2025 at 00:27, David E. Wheeler <david(at)justatheory(dot)com>
wrote:

> Interesting point, though it looks like maybe the output doesn’t work that
> way? In his second post, Mankirat linked to the output from abidiff[1] and
> abicc[2] comparing 17.2 to 17.3. The latter is HTML, but abidiff’s plan is
> pretty straightforward text that reports a bunch of changes. I imagine
> it’ll need some massaging to determine which are proper ABI breaks.

Mankirat, did you try it with 17.0 to 17.1? That would be interesting, as
> there was an ABI break in 17.1[3].

I have attached below the compliance reports for that version. I had not
included it in the blog earlier, as it was complicated and some readers
might not understand.

But as per my understanding, the outputs given by abidiff are way too
detailed as compared to html report output by abi-compliance-checker for
the same PostgreSQL version, though it backfires abidiff's usefulness since
it lists all the symbols which got affected due to a change instead of
directly mentioning the root cause.
For example, in version 17.1 instability struct ResultRelInfo got changed
with a new data member, in execnodes.h file as per this blog[1], but the
abidiff report gives "14 functions with some indirect sub-type change" and
all those 14 were affected due to the same cause, i.e. ResultRelInfo struct
- thus making a need to parse the output in a better format, I believe.

> Generally, this looks like the right direction.
>
That's great :)

> As an additional tip, check the Python source code, they are doing
> something like that with libabigail as well.
>
Can you please provide some reference on that? - Do you mean something like
this[2]?

Regards,
Mankirat

[1]:
https://www.enterprisedb.com/blog/explaining-abi-breakage-postgresql-171
[2]:
https://developers.redhat.com/blog/2020/04/02/how-to-write-an-abi-compliance-checker-using-libabigail#the_python_based_abi_diff_checker