Эта глава объясняет интерфейс между основной системой Digital Q.DataBase и методами доступа к таблицам, которые управляют хранением таблиц. Основная система знает мало об этих методах доступа помимо указанного здесь, поэтому можно разрабатывать совершенно новые типы методов доступа, написав дополнительный код.

Каждый метод доступа к таблицам описывается строкой в системном каталоге pg_am. Запись pg_am задаёт имя и функцию-обработчик для метода доступа к таблицам. Эти записи можно создавать и удалять с помощью SQL-команд CREATE ACCESS METHOD и DROP ACCESS METHOD.

Функция-обработчик метода доступа к таблицам должна быть объявлена с одним аргументом типа internal и возвращать псевдотип table_am_handler. Аргумент является фиктивным значением, которое просто служит для предотвращения вызова функций-обработчиков напрямую из SQL-команд. Результатом функции должен быть указатель на структуру типа TableAmRoutine, которая содержит всё, что основной системе нужно знать для использования метода доступа к таблицам. Возвращаемое значение должно иметь время жизни сервера, что обычно достигается определением его как static const переменной в глобальной области видимости. Структура TableAmRoutine, также называемая API-структурой метода доступа, определяет поведение метода доступа с использованием обратных вызовов. Эти обратные вызовы являются указателями на обычные C-функции и не видны и не вызываемы на уровне SQL. Все обратные вызовы и их поведение определены в структуре TableAmRoutine (с комментариями внутри структуры, определяющими требования к обратным вызовам). Большинство обратных вызовов имеют функции-обёртки, которые документированы с точки зрения пользователя (а не разработчика) метода доступа к таблицам. Для подробностей обратитесь к файлу src/include/access/tableam.h.

Для реализации метода доступа разработчику, как правило, потребуется реализовать специфичный для AM тип слота таблицы кортежей (см. src/include/executor/tuptable.h), который позволяет коду вне метода доступа хранить ссылки на кортежи AM и получать доступ к столбцам кортежа.

В настоящее время способ, которым AM фактически хранит данные, довольно не ограничен. Например, возможно, но не обязательно, использовать общий буферный кеш postgres. Если он используется, вероятно, имеет смысл использовать стандартную структуру страницы Digital Q.DataBase, описанную в Раздел 7.15.6.

Одно довольно большое ограничение API методов доступа к таблицам заключается в том, что в настоящее время, если AM хочет поддерживать изменения и/или индексы, необходимо, чтобы каждый кортеж имел идентификатор кортежа (TID), состоящий из номера блока и номера элемента (см. также Раздел 7.15.6). Не строго необходимо, чтобы составные части TID имели тот же смысл, что они, например, имеют для heap, но если требуется поддержка bitmap-сканирования (она является опциональной), номер блока должен обеспечивать локальность.

Для устойчивости к сбоям AM может использовать WAL postgres или собственную реализацию. Если выбран WAL, можно использовать либо универсальные записи WAL, либо реализовать пользовательский менеджер ресурсов WAL.

Для реализации поддержки транзакций таким образом, чтобы позволял обращаться к разным методам доступа к таблицам в рамках одной транзакции, вероятно, необходимо тесно интегрироваться с механизмами в src/backend/access/transam/xlog.c.

Любой разработчик нового метода доступа к таблицам может обратиться к существующей реализации heap в файле src/backend/access/heap/heapam_handler.c для подробностей её реализации.