Re: Should we rename amapi.h and amapi.c?

Hi,

(Moving discussion from [1] to this thread)

On 2019-12-28 11:32:26 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2019-12-27 08:20:17 +0900, Michael Paquier wrote:
> >> Hm, I am not sure that it is actually that much used, such stuff is
> >> very specialized.
>
> > That's true for some of this, but e.g. genam.h is pretty widely
> > included. I mean, you had to adapt like 100+ files and while like 30 or
> > so of those are in implementation details of individual indexes, the
> > rest is not.
>
> This may suggest that we should think about an actual refactoring,
> rather than just mechanical renaming. Do these results mean that
> we've allowed index API details to bleed into the wrong places?

I think the biggest API bleed is systable_* - that's legitimately needed
in a lot of places. But not actually appropriately a part of
"generalized index access method definitions.".

Furthermore I think genam.h suffers from trying to provide somewhat
distinct sets of interfaces:
- general handling of indexes: index_open/close ...
- index scan implementation: index_beginscan, ...
index_parallelscan_initialize, ...
- systable scan implementation: systable_*
- low level index interaction helpers: IndexBuildResult, IndexVacuumInfo,
- index implementation helpers: index_store_float8_orderby_distances, ...

Now obviously we'd not want to split things quite that granular, but it
does seem like separating out external interface, systable_*, and AM
oriented things into a header each would make some sense.

Greetings,

Andres Freund

[1] https://postgr.es/m/18016.1577550746%40sss.pgh.pa.us