Определение интерфейса для табличных методов доступа

В этой главе объясняется интерфейс между основной системой PostgreSQL и методами доступа к таблицам, которые управляют хранением данных в таблицах. Ядро системы мало что знает об этих методах доступа, кроме того, что указано здесь, поэтому можно разработать совершенно новые типы методов доступа, написав дополнительный код.

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

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

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

В настоящее время способ хранения данных в AM достаточно неограничен. Например, можно, но не обязательно, использовать общий буферный кэш PostgreSQL. В случае его использования, скорее всего, имеет смысл использовать стандартную разметку страниц PostgreSQL, как описано в разделе «Макет страницы базы данных».

Одним из довольно серьезных ограничений API метода доступа к таблице является то, что в настоящее время, если AM хочет поддерживать модификации и/или индексы, необходимо, чтобы каждый кортеж имел идентификатор кортежа (TID), состоящий из номера блока и номера элемента (см. также раздел «Макет страницы базы данных»). Не обязательно, чтобы подчасти TID имели то же значение, что, например, для кучи, но если желательна поддержка растрового сканирования (это необязательно), номер блока должен обеспечивать локальность.

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

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

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