×
Мы обрабатываем cookies, чтобы сделать наш сайт удобнее и персонализированнее для вас. Подробнее: политика использования «cookies» и «политики конфиденциальности».

Для самостоятельной настройки ознакомьтесь с инструкцией

Дополнительные настройки cookies в браузерах

Файлы cookie автоматически загружаются в ваш браузер при посещении веб-сайта. У вас есть возможность управлять этими файлами. Если Вы не согласны с использованием файлов cookies, запретите их сохранение на своём устройстве, удалите уже имеющиеся файлы cookies через настройки браузера или прекратите использование сайта.

При отключении обработки cookie наш сайт продолжит функционировать, однако будут использоваться исключительно необходимые технические файлы, без которых работа ресурса невозможна.

Инструкция по отключению cookies
Принять
Настроить
Отклонить

ДОКУМЕНТАЦИЯ

Выберите версию, форк и язык для СУБД Digital Q.DataBase, чтобы прочитать или скачать всю документацию.
Техподдержка
Документация
Диасофт
Авторские права © 2016–2025 ООО "Диасофт Экосистема"
Скачать всю документацию:

5.1.18. Инфраструктура сборки расширений

Если вы планируете распространять свои Digital Q.DataBase модули расширения, создание для них переносимой системы сборки может оказаться довольно сложной задачей. Поэтому в составе Digital Q.DataBase поставляется инфраструктура сборки расширений, называемая PGXS, которая позволяет собирать простые модули расширения для уже установленного сервера. PGXS в основном предназначена для расширений, включающих код на языке C, хотя она может использоваться и для расширений на чистом SQL. Обратите внимание, что PGXS не является универсальной средой сборки для любого программного обеспечения, взаимодействующего с Digital Q.DataBase; она лишь автоматизирует стандартные правила сборки простых серверных модулей расширения. Для более сложных пакетов может потребоваться разработка собственной системы сборки.

Чтобы использовать PGXS инфраструктуру для своего расширения, необходимо написать простой makefile. В этом файле следует задать несколько переменных и включить глобальный PGXS makefile. Ниже приведен пример сборки модуля расширения под названием isbn_issn, состоящего из разделяемой библиотеки, содержащей код на языке C, управляющего файла расширения, SQL-скрипта, заголовочного файла (необходимого только в том случае, если другим модулям может потребоваться доступ к функциям расширения напрямую, минуя SQL), и текстового файла документации:

MODULES = isbn_issn
EXTENSION = isbn_issn
DATA = isbn_issn--1.0.sql
DOCS = README.isbn_issn
HEADERS_isbn_issn = isbn_issn.h

PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

Последние три строки всегда должны оставаться неизменными. Ранее в этом файле вы определяете переменные или добавляете собственные make правила.

Задайте одну из этих трех переменных, чтобы указать объект сборки:

MODULES #

список объектов разделяемых библиотек, собираемых из исходных файлов с тем же основа имени (не включайте суффиксы библиотек в данный список)

MODULE_big #

разделяемая библиотека, собираемая из нескольких исходных файлов (перечислите объектные файлы в OBJS)

PROGRAM #

исполняемая программа для сборки (перечислите объектные файлы в OBJS)

Также могут быть установлены следующие переменные:

EXTENSION #

имя (имена) расширения; для каждого имени необходимо предоставить расширение.control файл, который будет установлен в префикс/share/extension

MODULEDIR #

подкаталог префикс/share в который должны быть установлены файлы DATA и DOCS (если не задано, по умолчанию используется расширение если EXTENSION установлено, или contrib если нет)

DATA #

произвольные файлы для установки в префикс/share/$MODULEDIR

DATA_built #

произвольные файлы для установки в префикс/share/$MODULEDIR, которые необходимо предварительно собрать

DATA_TSEARCH #

произвольные файлы для установки в префикс/share/tsearch_data

DOCS #

произвольные файлы для установки в префикс/doc/$MODULEDIR

HEADERS
HEADERS_built #

Файлы для (необязательной сборки и) установки в префикс/include/server/$MODULEDIR/$MODULE_big.

В отличие от DATA_built, файлы в HEADERS_built не удаляются при выполнении цели clean target; если их требуется удалить, также добавьте их в EXTRA_CLEAN или добавьте собственные правила для выполнения этой операции.

HEADERS_$MODULE
HEADERS_built_$MODULE #

Файлы, подлежащие установке (при необходимости после сборки), в каталог префикс/include/server/$MODULEDIR/$MODULE, где $MODULE должно соответствовать имени модуля, используемому в MODULES или MODULE_big.

В отличие от DATA_built, файлы в HEADERS_built_$MODULE не удаляются при выполнении цели clean target; если их требуется удалить, также добавьте их в EXTRA_CLEAN или добавьте собственные правила для выполнения этой операции.

Допускается использование обеих переменных для одного и того же модуля или любого их сочетания, кроме случаев, когда в списке присутствуют два имени модулей, MODULES различающиеся только наличием префикса built_, что приведет к неоднозначности. В этом (надеемся, маловероятном) случае следует использовать только HEADERS_built_$MODULE переменные.

SCRIPTS #

файлы сценариев (не исполняемые файлы) для установки в префикс/bin

SCRIPTS_built #

файлы сценариев (не исполняемые файлы) для установки в префикс/bin, которые необходимо предварительно собрать

REGRESS #

список сценариев регрессионного тестирования (без суффикса), см. ниже

REGRESS_OPTS #

дополнительные ключи для передачи в pg_regress

ISOLATION #

список сценариев тестирования изоляции, подробности см. ниже

ISOLATION_OPTS #

дополнительные ключи для передачи в pg_isolation_regress

TAP_TESTS #

параметр, определяющий необходимость запуска TAP-тестов, см. ниже

NO_INSTALL #

не определяйте install цель, полезная для тестовых модулей, результаты сборки которых не требуют установки

NO_INSTALLCHECK #

не определяйте installcheck цель; полезно, например, если тесты требуют специальной конфигурации или не используют pg_regress

EXTRA_CLEAN #

дополнительные файлы для удаления при выполнении make clean

PG_CPPFLAGS #

будет добавлено в начало значения CPPFLAGS

PG_CFLAGS #

будет добавлено в конец значения CFLAGS

PG_CXXFLAGS #

будет добавлено в конец значения CXXFLAGS

PG_LDFLAGS #

будет добавлено в начало значения LDFLAGS

PG_LIBS #

будет добавлено в PROGRAM строку компоновки

будет добавлено в MODULE_big строку компоновки

PG_CONFIG #

путь к pg_config программа для Digital Q.DataBase экземпляра установки, для которого выполняется сборка (обычно просто pg_config для использования первого найденного в вашей переменной PATH)

Разместите этот makefile под именем Makefile в директории, в которой находится ваше расширение. Затем вы можете выполнить make для компиляции, а затем make install для установки вашего модуля. По умолчанию расширение компилируется и устанавливается для той Digital Q.DataBase инсталляции, которая соответствует первой pg_config программе найденной в вашем PATH. Вы можете использовать другую инсталляцию, установив значение PG_CONFIG так, чтобы оно указывало на её pg_config программу либо в make-файле, либо в make командной строке.

Вы также можете запустить make в директории вне дерева исходных кодов вашего расширения, если хотите хранить директорию сборки отдельно. Эта процедура также называется VPATH сборкой. Порядок действий:

mkdir build_dir
cd build_dir
make -f /path/to/extension/source/tree/Makefile
make -f /path/to/extension/source/tree/Makefile install

В качестве альтернативы вы можете настроить директорию для VPATH-сборки тем же способом, который используется для основного исходного кода. Один из способов сделать это — использовать основной сценарий config/prep_buildtree. После завершения этой процедуры сборку можно выполнить, установив make переменную VPATH следующим образом:

make VPATH=/path/to/extension/source/tree
make VPATH=/path/to/extension/source/tree install

Данная процедура позволяет работать с более широким спектром структур каталогов.

Сценарии, перечисленные в REGRESS переменной, используются для регрессионного тестирования модуля, которое можно запустить с помощью команды make installcheck после выполнения make install. Для корректной работы необходимо наличие запущенного Digital Q.DataBase сервера. Файлы сценариев, перечисленные в REGRESS должны находиться в подкаталоге с именем sql/ в каталоге расширения. Данные файлы должны иметь расширение .sql, которое не следует включать в REGRESS список в make-файле. Для каждого теста также должен существовать файл, содержащий ожидаемый результат, в подкаталоге с именем expected/также должен присутствовать файл с ожидаемым результатом, имеющий то же основное имя и расширение .out. make installcheck запускает каждый тестовый сценарий с использованием psqlи сравнивает полученный результат с соответствующим эталонным файлом. Любые расхождения будут записаны в файл regression.diffs в формате diff -c format. Обратите внимание, что попытка выполнения теста при отсутствии файла с ожидаемым результатом будет зафиксирована как «trouble», поэтому убедитесь в наличии всех необходимых эталонных файлов.

Сценарии, перечисленные в ISOLATION используются для тестов, проверяющих работу параллельных сессий с вашим модулем, которые можно инициировать с помощью make installcheck после выполнения make install. Для обеспечения корректной работы необходимо наличие запущенного экземпляра Digital Q.DataBase сервер. Файлы сценариев, указанные в ISOLATION должны находиться в подкаталоге с именем specs/ в каталоге вашего расширения. Эти файлы должны иметь расширение .spec, которое не следует включать в ISOLATION список в make-файле. Для каждого теста также должен существовать файл, содержащий ожидаемый результат, в подкаталоге с именем expected/также должен присутствовать файл с ожидаемым результатом, имеющий то же основное имя и расширение .out. make installcheck выполняет каждый сценарий тестирования и сравнивает полученный результат с соответствующим эталонным файлом. Все различия будут записаны в файл output_iso/regression.diffs в diff -c format. Обратите внимание: попытка запуска теста, для которого отсутствует эталонный файл, будет отмечена как «trouble», поэтому убедитесь в наличии всех эталонных файлов.

TAP_TESTS позволяет использовать TAP-тесты. Данные каждого запуска находятся в подкаталоге с именем tmp_check/.

Подсказка

Самый простой способ создания ожидаемых файлов заключается в создании пустых файлов с последующим выполнением тестового запуска (который, разумеется, выявит различия). Проверьте фактические файлы результатов, находящиеся в results/ каталоге (для тестов в REGRESS), или output_iso/results/ каталоге (для тестов в ISOLATION), а затем скопируйте их в expected/ если они соответствуют ожидаемым результатам теста.

Наверх
свяжитесь
с нами
контакты
Для прямой связи с нами вы можете использовать контакты ниже, либо оставить заявку через форму обратной связи, и мы обязательно свяжемся с вами

*поля обязательные к заполнению