On Jun 4, 2024, at 03:18, Peter Eisentraut <pe...@eisentraut.org> wrote:
> This could possibly be avoided by renaming the symbol in backbranches. Maybe
> something like
>
> #define InitResultRelInfo InitResultRelInfo2
>
> Then you'd get a specific error message when loading the module, rather than
> a crash.
That sounds more useful, yes. Is that a practice the project would consider
adopting?
There’s also oracle_fdw@d137d15[1], which says:
> 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:
``` 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 any guarantees in minor releases?
Best,
David
[1]:
https://github.com/laurenz/oracle_fdw/commit/d137d15edca8c67df1e5cccca01f417f4833b028
[2]:
https://github.com/postgres/postgres/commit/68fab04f7c2a07c5308e3d2957198ccd7a80ebc5#diff-bb6fa74cb115e19684092f0938131cd5d99b26fa2d49480f7ea7f28e937a7fb4
