Записки программиста

Наиболее простой способ работы с таблицами из расширений PostgreSQL заключается в использовании Server Programming Interface (SPI). С этим интерфейсом мы познакомились в рамках статьи Учимся писать расширения на языке C для PostgreSQL. Однако SPI имеет накладные расходы на парсинг и планирование запросов. Поэтому в простых сценариях выгоднее работать с таблицами напрямую. Звучит страшновато, но на самом деле это не так сложно.

Примечание: Перед прочтением этой заметки рекомендую прочитать предыдущие статьи серии, если вдруг вы их пропустили: первая, вторая и третья.

Замечательную статью по этой теме в свое время написал Юрий Журавлев. Но за прошедшие ~7 лет код PostgreSQL сильно изменился. Если использовать примеры из статьи как есть, то они либо не скомпилируются, либо упадут с ошибкой. Интересно, быстро ли потеряет актуальность эта статья, и кто напишет ее обновленную версию?

Для примера рассмотрим расширение для работы с телефонной книгой:

Тип NAME — это строка длиной до 63-х символов. PostgreSQL активно использует данный тип в своем каталоге, см описание таблиц pg_proc, pg_enum, и прочих. Для хранения коротких строк в своем расширении вы наверняка воспользуетесь именно NAME, а не TEXT. Далее станет понятно, почему.

В коде расширения схема БД должна быть описана как-то так:

Думаю, что здесь особые пояснения не требуются. Имена структур и enum’ов соответствуют соглашениям, принятым в коде PostgreSQL.

Для работы с таблицей нам понадобится ее object identifier, или Oid. Oid’ы представляют собой первичные ключи в каталоге PostgreSQL. Каждая таблица, хранимая процедура, тип, и так далее — все имеет уникальный Oid. Существует ряд типов-алиасов к Oid. Например, для Oid’ов таблиц есть тип regclass. Внутри это точно такой же Oid, но пользователю regclass отображается, как имя соответствующей таблицы.

Преобразовать имя таблицы в ее Oid можно с помощью функции to_regclass(). Как и любая другая хранимка, она может быть вызвана из кода на C:

Запись в таблицу может быть произведена таким образом:

Следующий id мы здесь получаем точно так же, как это делает PostgreSQL — вызываем nextval(), передав ему Oid соответствующего sequence. Само собой разумеется, я не помню такие вещи наизусть. Все это прямым текстом написано в определении таблицы. Достаточно сказать \d phonebook в psql, и все сразу понятно.

Остальной код достаточно очевиден — открыть таблицу с правильной блокировкой, создать кортеж, записать кортеж в таблицу, освободить кортеж, закрыть таблицу. Всю сложную работу за нас тут делает CatalogTupleInsert(). Процедура не просто записывает кортеж, но и должным образом обновляет все индексы. Название как бы намекает, что PostgreSQL использует процедуру для работы с собственным каталогом.

Как проверить, что индексы действительно обновляются? PostgreSQL напрямую не позволяет читать содержимое индексов. Зато в комплекте c PostgreSQL идет замечательное расширение pageinspect. Помимо прочего, в расширении есть функция bt_page_items(), которая как раз позволяет читать из индексов. В качестве домашнего задания предлагаю вам убедиться, что приведенный код действительно не портит индексы таблицы.

Еще есть CatalogTupleUpdate() и CatalogTupleDelete() для обновления и удаления кортежей соответственно. Они не сложнее CatalogTupleInsert(), поэтому не будем подробно на них останавливаться. Заинтересованные читатели найдут примеры использования данных процедур в полной версии исходников к посту.

Если вставка, обновление и удаление позади, то что осталось? Правильно, чтение. Самый простой вариант, последовательно сканирующий всю таблицу, выглядит так:

Особого внимания заслуживает макрос GETSTRUCT(). Он позволяет из кортежа получить указатель на ранее объявленную структуру FormData_phonebook. Такой код часто используется внутри PostgreSQL. Но чтобы это работало, должно выполняться несколько условий. Таблица не должна использовать типы переменного размера, такие, как TEXT. Все столбцы должны быть объявлены, как NOT NULL. Плюс к этому, следует соблюдать особую осторожность при изменении схемы БД. Последний вопрос выходит за рамки статьи.

Если вы не согласны на названные ограничения, вместо GETSTRUCT() следует воспользоваться heap_deform_tuple():

Это более дорогой способ, зато он работает как с TEXT, так и с NULL‘ами. Оправдано его использование или нет, определяется частотой обращений к таблице, и в целом решаемой задачей.

Чем больше объем данных, тем выгоднее поддерживать индекс по таблице, чтобы каждый раз не сканировать ее целиком. Сканирование с использованием индекса выглядит так:

Важно! При возвращении из index_getnext_slot в общем случае нужно проверять значение scan->xs_recheck. Если оно равно true, нужно перепроверить на вызывающей стороне, что кортеж соответствует условиям поиска. В некоторых случаях функция сама не может сделать это эффективно, поскольку не имеет доступа ко всем необходимым данным. Для простоты в приведенном коде эта проверка не делается.

К сожалению, в рамках одной статьи невозможно погрузиться во все дебри. Заинтересованным читателям я рекомендую найти в исходниках PostgreSQL использованные выше типы и процедуры, почитать комментарии к ним, посмотреть их реализацию и примеры использования. С исходным кодом TimescaleDB тоже можно ознакомиться.

А у меня на этом все. Полную версию исходников к посту вы найдете на GitHub.

Дополнение: В продолжение темы см Внутренности PostgreSQL: страницы и кортежи, Расширения PostgreSQL: разделяемая память и локи, и далее по ссылкам.

Метки: C/C++, PostgreSQL, СУБД.