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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Should we rename amapi.h and amapi.c?
Дата
Msg-id 20191224025712.GG34339@paquier.xyz
обсуждение исходный текст
Ответ на Re: Should we rename amapi.h and amapi.c?  (Ashwin Agrawal <aagrawal@pivotal.io>)
Ответы 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>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Condition variables vs interrupts
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Increase footprint of %m and reduce strerror()