Re: Should we rename amapi.h and amapi.c? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Should we rename amapi.h and amapi.c?
Date
Msg-id 20191224025712.GG34339@paquier.xyz
Whole thread Raw
In response to Re: Should we rename amapi.h and amapi.c?  (Ashwin Agrawal <aagrawal@pivotal.io>)
Responses Re: Should we rename amapi.h and amapi.c?  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Should we rename amapi.h and amapi.c?  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Mon, Dec 23, 2019 at 12:28:36PM -0800, Ashwin Agrawal wrote:
> I had raised the same earlier and [1] has response from Andres, which was
> "We probably should rename it, but not in 12..."
>
> [1]
> https://www.postgresql.org/message-id/20190508215135.4eljnhnle5xp3jwb%40alap3.anarazel.de

Okay, glad to see that this has been mentioned.  So let's do some
renaming for v13 then.  I have studied first if we had better remove
amapi.c, then move amvalidate() to amvalidate.c and the handler lookup
routine to indexam.c as it already exists, but keeping things ordered
as they are makes sense to limit spreading too much dependencies with
the syscache mainly, so instead the attached patch does the following
changes:
- amapi.h -> indexam.h
- amapi.c -> indexamapi.c.  Here we have an equivalent in access/table/
as tableamapi.c.
- amvalidate.c -> indexamvalidate.c
- amvalidate.h -> indexamvalidate.h
- genam.c -> indexgenam.c

Please note that we have also amcmds.c and amcmds.c in the code, but
the former could be extended to have utilities for table AMs, and the
latter applies to both, so they are better left untouched in my
opinion.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Condition variables vs interrupts
Next
From: Michael Paquier
Date:
Subject: Re: Increase footprint of %m and reduce strerror()