Re: [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM
От | Nikolay Shaplov |
---|---|
Тема | Re: [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM |
Дата | |
Msg-id | 5867745.FjVmo6n3G8@x200m обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Move all am-related reloption code intosrc/backend/access/[am-name] and get rid of relopt_kind for custom AM (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
В письме от 17 марта 2017 14:21:26 пользователь Alvaro Herrera написал: > Please make sure to mark functions as static (e.g. bringetreloptcatalog). I am a bit confused here: For brin and nbtree this is a good idea: brin.c and nbtree.c has AM-handler inside it, and there are other static functions there. Adding one more static function here seems to be quite logical. For gin, gist and spgist, authors seems to use [index_name]_private.h files to hide internal functions from outside code. In ginutil.c and spgutils.c, where AM-handler is located, there is no static functions at all... gist.c has, but I think I should write similar code for all *_private.h indexes. So I think it wold be good to hide catalog function via *_pricate.h include file for these three indexes. hash.c is quite a mess... There is no hash_private.h, AM-handles is located in hash.c, that has "This file contains only the public interface routines." comment at the beginning, and there is no static functions inside. I do not know what is the right way to hide hashgetreloptcatalog function here... What would you advise? -- Nikolay Shaplov, independent Perl & C/C++ developer. Available for hire.
В списке pgsql-hackers по дате отправления: