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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Should we rename amapi.h and amapi.c?
Date: 2020-01-02 14:21:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


(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.


Andres Freund


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-01-02 14:22:33 Commit fest manager for 2020-01
Previous Message Robert Haas 2020-01-02 14:13:27 Re: Disallow cancellation of waiting for synchronous replication