Re: Proposal: Document ABI Compatibility - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposal: Document ABI Compatibility
Date
Msg-id 20240610193933.ktfygrkfcsdhspwu@awork3.anarazel.de
Whole thread Raw
In response to Re: Proposal: Document ABI Compatibility  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: Proposal: Document ABI Compatibility
List pgsql-hackers
Hi,

On 2024-06-10 15:05:32 -0400, David E. Wheeler wrote:
> > An API break in PostgreSQL 10.4 and 9.6.9 makes it impossible
> > to use these versions: the "extract_actual_join_clauses" function
> > gained an additional parameter.
> 
> The 10.4 commit is 68fab04, and it does indeed add a new function:

That's 6 years ago, not sure we can really learn that much from that.

And it's not like it's actually impossible, #ifdefs aren't great, but they are
better than nothing.


> ``` patch
> --- a/src/include/optimizer/restrictinfo.h
> +++ b/src/include/optimizer/restrictinfo.h
> @@ -36,6 +36,7 @@ extern List *get_actual_clauses(List *restrictinfo_list);
>  extern List *extract_actual_clauses(List *restrictinfo_list,
>                        bool pseudoconstant);
>  extern void extract_actual_join_clauses(List *restrictinfo_list,
> +                           Relids joinrelids,
>                             List **joinquals,
>                             List **otherquals);
>  extern bool join_clause_is_movable_to(RestrictInfo *rinfo, RelOptInfo *baserel);
> ```
> 
> I wonder if that sort of change could be avoided in backpatches, maybe by adding and using a
`extract_actual_join_clauses_compat`function and using that internally instead?
 
> 
> Or, to David C’s point, perhaps it would be better to say there are some categories of APIs that are not subject to
anyguarantees in minor releases?
 

I'm honestly very dubious that this is a good point to introduce a bunch of
formalism. It's a already a lot of work to maintain them, if we make it even
harder we'll end up more fixes not being backported, because it's not worth
the pain.

To be blunt, the number of examples raised here doesn't seem to indicate that
this is an area where we need to invest additional resources. We are already
severely constrained as a project by committer bandwidth, there are plenty
other things that seem more important to focus on.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Non-text mode for pg_dumpall
Next
From: Andres Freund
Date:
Subject: Re: RFC: adding pytest as a supported test framework