F.54. postgres_fdw
Модуль postgres_fdw
предоставляет обёртку сторонних данных postgres_fdw
, используя которую можно обращаться к данным, находящимся на внешних серверах Postgres Pro.
Функциональность этого модуля во многом пересекается с функциональностью старого модуля dblink. Однако postgres_fdw
предоставляет более прозрачный и стандартизированный синтаксис для обращения к удалённым таблицам и во многих случаях даёт лучшую производительность.
Чтобы подготовиться к обращению к удалённым данным через postgres_fdw
:
Установите расширение
postgres_fdw
с помощью команды CREATE EXTENSION.Создайте объект стороннего сервера, используя CREATE SERVER, который будет представлять удалённую базу данных, к которой вы хотите подключаться. Укажите свойства подключения, кроме
user
иpassword
, в параметрах объекта сервера.Создайте сопоставление пользователей, используя CREATE USER MAPPING, для каждого пользователя базы, которому нужен доступ к удалённому серверу. Укажите имя и пароль удалённого пользователя в параметрах
user
иpassword
сопоставления.Создайте стороннюю таблицу, используя CREATE FOREIGN TABLE или IMPORT FOREIGN SCHEMA, для каждой удалённой таблицы, к которой вы хотите обращаться. Столбцы сторонней таблицы должны соответствовать столбцам целевой удалённой таблицы. Однако вы можете использовать локально имена таблиц и/или столбцов, отличные от удалённых, если укажете корректные удалённые имена в параметрах объекта сторонней таблицы.
После этого для обращения к данным, хранящимся в нижележащей удалённой таблице, вам нужно только выполнять SELECT
. Вы также можете изменять данные в удалённой таблице, выполняя INSERT
, UPDATE
, DELETE
или COPY
. (Разумеется, удалённый пользователь, указанный в сопоставлении, должен иметь необходимые права для этого.)
Заметьте, что в настоящее время в postgres_fdw
не поддерживаются операторы INSERT
с предложением ON CONFLICT DO UPDATE
. Однако предложение ON CONFLICT DO NOTHING
поддерживается, при отсутствии указания для выбора уникального индекса. Заметьте также, что postgres_fdw
поддерживает перемещение строк, вызванное командами UPDATE
, выполняемыми для секционированных таблиц. Однако в настоящее время невозможно выполнить изменение, при котором удалённая секция, выбранная для добавления перемещаемой строки, также является целевой секцией для UPDATE
и должна модифицироваться позже той же командой.
Обычно рекомендуется объявлять столбцы сторонней таблицы точно с теми же типами данных и правилами сортировки, если они применимы, как у целевых столбцов удалённой таблицы. Хотя postgres_fdw
в настоящее время довольно лоялен к преобразованиям типов данных при необходимости, но когда типы или правила сортировки не совпадают, возможны неожиданные семантические аномалии, вследствие того, что удалённый сервер будет обрабатывать условия запроса не так, как локальный сервер.
Заметьте, что сторонняя таблица может быть объявлена с меньшим количеством или с другим порядком столбцов, чем в нижележащей удалённой таблице. Сопоставление столбцов удалённой таблицы осуществляется по имени, а не по позиции.
F.54.1. Параметры обёртки для postgres_fdw
F.54.1.1. Параметры подключения
Для стороннего сервера, настраиваемого с использованием обёртки сторонних данных postgres_fdw
, можно задать те же параметры, что принимает libpq в строках подключения, как описано в Подразделе 35.1.2, за исключением следующих недопустимых параметров:
user
иpassword
(их следует задавать в сопоставлениях пользователей)client_encoding
(автоматически принимается равной локальной кодировке сервера)fallback_application_name
(всегдаpostgres_fdw
)
Подключаться к сторонним серверам без аутентификации по паролю могут только суперпользователи, поэтому в сопоставлениях для обычных пользователей всегда нужно задавать пароль (password
).
F.54.1.2. Параметры имени объекта
Эти параметры позволяют управлять тем, как на удалённый сервер Postgres Pro будут передаваться имена, фигурирующие в операторах SQL. Данные параметры нужны, когда сторонняя таблица создаётся с именами, отличными от имён удалённой таблицы.
schema_name
Этот параметр, который может задаваться для сторонней таблицы, указывает имя схемы для обращения к этой таблице на удалённом сервере. Если данный параметр опускается, применяется схема сторонней таблицы.
table_name
Этот параметр, который может задаваться для сторонней таблицы, указывает имя таблицы для обращения к этой таблице на удалённом сервере. Если данный параметр опускается, применяется имя сторонней таблицы.
column_name
Этот параметр, который может задаваться для столбца сторонней таблицы, указывает имя столбца для обращения к этому столбцу на удалённом сервере. Если данный параметр опускается, применяется исходное имя столбца.
F.54.1.3. Параметры оценки стоимости
Модуль postgres_fdw
получает удалённые данные, выполняя запросы на удалённых серверах, поэтому в идеале ожидаемая стоимость сканирования сторонней таблицы должна равняться стоимости выполнения на удалённом сервере плюс издержки сетевого взаимодействия. Самый надёжный способ получить такие оценки — узнать стоимость у удалённого сервера и добавить некоторую надбавку — но для простых запросов может быть невыгодно передавать дополнительный запрос, только чтобы получить оценку стоимости. Поэтому postgres_fdw
предоставляет следующие параметры, позволяющие управлять вычислением оценки стоимости:
use_remote_estimate
Этот параметр, который может задаваться для сторонней таблицы или для стороннего сервера, определяет, будет ли
postgres_fdw
выполнять удалённо командыEXPLAIN
для получения оценок стоимости. Параметр, заданный для сторонней таблицы, переопределяет параметр сервера, но только для данной таблицы. Значение по умолчанию —false
(выкл.).fdw_startup_cost
Этот параметр, который может задаваться для стороннего сервера, устанавливает числовое значение, добавляемое к оценке стоимости запуска для любого сканирования сторонней таблицы на этом сервере. Он выражает дополнительные издержки на установление подключения, разбор и планирование запроса на удалённой стороне и т. д. Значение по умолчанию —
100
.fdw_tuple_cost
Этот параметр, который может задаваться для стороннего сервера, устанавливает числовое значение, выражающее дополнительную цену чтения одного кортежа из сторонней таблицы на этом сервере. Это число можно увеличить или уменьшить, отражая меньшую или большую фактическую скорость сетевого взаимодействия с удалённым сервером. Значение по умолчанию —
0.01
.
Когда поведение use_remote_estimate
включено, postgres_fdw
получает количество строк и оценку стоимости с удалённого сервера, а затем добавляет к оценке стоимости fdw_startup_cost
и fdw_tuple_cost
. Когда поведение use_remote_estimate
отключено, postgres_fdw
рассчитывает число строк и оценку стоимости локально, а затем так же добавляет к этой оценке fdw_startup_cost
и fdw_tuple_cost
. Локальная оценка может быть точной только при условии наличия локальной копии статистики удалённых таблиц. Обновить эту статистику для сторонней таблицы можно с помощью команды ANALYZE; при этом удалённая таблица будет просканирована, и по её содержимому будут вычислена и сохранена статистика как для локальной таблицы. Локальное хранение статистики может быть полезно для сокращения издержек планирования для удалённой таблицы — но если удалённая таблица меняется часто, локальная статистика будет быстро устаревать.
F.54.1.4. Параметры удалённого выполнения
По умолчанию ограничения WHERE
, содержащие встроенные операторы и функции, обрабатываются на удалённом сервере, а ограничения, содержащие вызовы не встроенных функций, проверяются локально после получения строк. Если же расширенные функции доступны на удалённом сервере и можно рассчитывать, что они дадут те же результаты, что и локально, производительность можно увеличить, передавая и такие предложения WHERE
для удалённого выполнения. Этим поведением позволяет управлять следующий параметр:
extensions
В этом параметре задаётся список имён расширений Postgres Pro через запятую, которые установлены и имеют совместимые версии и на локальном, и на удалённом сервере. Относящиеся к перечисленным расширениям и при этом постоянные (immutable) функции и операторы могут передаваться на выполнение удалённому серверу. Этот параметр можно задать только для стороннего сервера, но не для таблицы.
При использовании параметра
extensions
пользователь сам отвечает за то, чтобы перечисленные расширения существовали и их поведение было одинаковым на локальном и удалённом сервере. В противном случае удалённые запросы могут выдавать ошибки или неожиданные результаты.fetch_size
Этот параметр определяет, сколько строк должна получать
postgres_fdw
в одной операции выборки. Его можно задать для сторонней таблицы или стороннего сервера. Значение по умолчанию —100
строк.
F.54.1.5. Параметры изменения данных
По умолчанию все сторонние таблицы, доступные через postgres_fdw
, считаются допускающими изменения. Это можно переопределить с помощью следующего параметра:
updatable
Этот параметр определяет, будет ли
postgres_fdw
допускать изменения в сторонних таблицах посредством командINSERT
,UPDATE
иDELETE
. Его можно задать для сторонней таблицы или для стороннего сервера. Параметр, определённый на уровне таблицы, переопределяет параметр уровня сервера. Значение по умолчанию —true
(изменения разрешены).Конечно, если удалённая таблица на самом деле не допускает изменения, всё равно произойдёт ошибка. Использование этого параметра прежде всего позволяет выдать ошибку локально, не обращаясь к удалённому серверу. Заметьте, однако, что представление
information_schema
будет показывать, что определённая сторонняя таблицаpostgres_fdw
является изменяемой (или нет), согласно значению данного параметра, не проверяя это на удалённом сервере.
F.54.1.6. Параметры импорта
Обёртка postgres_fdw
позволяет импортировать определения сторонних таблиц с применением команды IMPORT FOREIGN SCHEMA. Эта команда создаёт на локальном сервере определения сторонних таблиц, соответствующие таблицам или представлениям, существующим на удалённом сервере. Если импортируемые удалённые таблицы содержат столбцы пользовательских типов данных, на локальном сервере должны быть совместимые типы с теми же именами.
Поведение процедуры импорта можно настроить следующими параметрами (задаваемыми в команде IMPORT FOREIGN SCHEMA
):
import_collate
Этот параметр устанавливает, будут ли в определения сторонних таблиц, импортируемых с внешнего сервера, включаться характеристики столбцов
COLLATE
. По умолчанию они включаются. Вам может потребоваться отключить его, если на удалённом сервере набор имён правил сортировки отличается от локального, что скорее всего будет иметь место, если серверы работают в разных операционных системах. Тем не менее отключение чревато тем, что правила сортировки в столбцах импортируемых таблиц не совпадут с правилами для нижележащих данных, что приведёт к аномальному поведению запросов.Даже когда этот параметр равен
true
, импортировать столбцы с правилом сортировки, выбираемым на удалённом сервере по умолчанию, рискованно. Столбцы импортируются со свойствомCOLLATE "default"
, а в результате будет применяться правило сортировки, выбираемое по умолчанию на локальном сервере, которое может отличаться от выбираемого на удалённом.import_default
Этот параметр устанавливает, будут ли в определения сторонних таблиц, импортируемых с внешнего сервера, включаться заданные для столбцов выражения
DEFAULT
. По умолчанию они не включаются. Если вы включите этот параметр, остерегайтесь выражений по умолчанию, которые могут вычисляться на локальном сервере не так, как на удалённом; например, частый источник проблем —nextval()
. Если в импортируемом выражении используются функции или операторы, несуществующие локально, командаIMPORT
в целом выдаст сбой.import_generated
Этот параметр определяет, включаются ли выражения генерируемых столбцов (
GENERATED
) в определения сторонних таблиц, импортируемых со стороннего сервера. Значение по умолчанию —true
. ВыполнениеIMPORT
завершится ошибкой, если в импортируемом генерирующем выражении используются функции или операторы, не существующие локально.import_not_null
Этот параметр устанавливает, будут ли в определения сторонних таблиц, импортируемых с внешнего сервера, включаться ограничения столбцов
NOT NULL
. По умолчанию они включаются.
Заметьте, что никакие другие ограничения, кроме NOT NULL
, из удалённых таблиц импортироваться не будут. Хотя Postgres Pro поддерживает ограничения CHECK
для сторонних таблиц, никаких средств для автоматического импорта их нет из-за риска различного вычисления выражения ограничения на локальном и удалённом серверах. Любая такая несогласованность в поведении ограничений CHECK
могла бы привести к сложно выявляемым ошибкам в оптимизации запросов. Поэтому, если вы хотите импортировать ограничения CHECK
, вы должны сделать это вручную и должны внимательно проверить семантику каждого. Более подробно интерпретация ограничений CHECK
для сторонних таблиц описана в CREATE FOREIGN TABLE.
Таблицы или сторонние таблицы, являющиеся секциями некоторой другой таблицы, исключаются автоматически. Секционированные таблицы импортируются, только если они не являются секциями каких-либо других таблиц. Так как все данные могут быть доступны через секционированную таблицу, являющуюся вершиной в иерархии секционирования, при таком подходе должен быть возможен доступ ко всем данным без создания дополнительных объектов.
F.54.2. Управление соединением
Модуль postgres_fdw
устанавливает соединение со сторонним сервером при первом запросе, в котором участвует сторонняя таблица, связанная со сторонним сервером. Это соединение сохраняется и повторно используется для последующих запросов в том же сеансе. Однако если для обращения к стороннему серверу задействуются разные пользователи (сопоставления пользователей), отдельное соединение устанавливается для каждого сопоставления пользователей.
F.54.3. Управление транзакциями
В процессе выполнения запроса, в котором участвуют какие-либо удалённые таблицы на стороннем сервере, postgres_fdw
открывает транзакцию на удалённом сервере, если такая транзакция ещё не была открыта для текущей локальной транзакции. Эта удалённая транзакция фиксируется или прерывается, когда фиксируется или прерывается локальная транзакция. Подобным образом реализуется и управление точками сохранения.
Для удалённой транзакции выбирается режим изоляции SERIALIZABLE
, когда локальная транзакция открыта в режиме SERIALIZABLE
; в противном случае применяется режим REPEATABLE READ
. Этот выбор гарантирует, что если запрос сканирует несколько таблиц на удалённом сервере, он будет получать согласованные данные одного снимка для всех сканирований. Как следствие, последовательные запросы в одной транзакции будут видеть одни данные удалённого сервера, даже если на нём параллельно происходят изменения, вызванные другими действиями. Это поведение ожидаемо для локальной транзакции в режимах SERIALIZABLE
и REPEATABLE READ
, но для локальной транзакции в режиме READ COMMITTED
оно может быть неожиданным. В будущих выпусках Postgres Pro эти правила могут быть изменены.
Заметьте, что подготовку удалённой транзакции для двухфазной фиксации postgres_fdw
в настоящее время не поддерживает.
F.54.4. Оптимизация удалённых запросов
Обёртка postgres_fdw
пытается оптимизировать удалённые запросы, уменьшая объём обмена данными со сторонними серверами. Для этого она может передавать на выполнение удалённому серверу предложения WHERE
и не получать столбцы таблицы, не требующиеся для текущего запроса. Чтобы уменьшить риск некорректного выполнения запросов, предложения WHERE
передаются удалённому серверу, только если в них используются типы данных, операторы и функции, встроенные в ядро или относящиеся к расширениям, перечисленным в параметре extensions
. Операторы и функции в таких предложениях также должны быть постоянными (IMMUTABLE
). Для запросов UPDATE
или DELETE
обёртка postgres_fdw
пытается оптимизировать выполнение, передавая весь запрос на удалённый сервер, если в запросе нет предложения WHERE
, которое нельзя было бы передать, не выполняется локальное соединение, в целевой таблице отсутствуют хранимые генерируемые столбцы и локальные триггеры BEFORE
/AFTER
уровня строки, а в родительских представлениях нет ограничения CHECK OPTION
. Кроме того, в запросах UPDATE
выражения, присваиваемые целевым столбцам, должны задействовать только встроенные типы данных и постоянные (IMMUTABLE
) операторы и функции, чтобы уменьшить риск неверного выполнения запроса.
Когда обёртка postgres_fdw
обнаруживает соединение сторонних таблиц на одном стороннем сервере, она передаёт всё соединение этому серверу, если только по какой-то причине не решит, что будет эффективнее выбирать строки из каждой таблицы по отдельности, или сопоставляемые при обращении к таблицам пользователи оказываются разными. При передаче предложений JOIN
принимаются те же меры предосторожности, что были описаны выше для предложений WHERE
.
Запрос, фактически отправляемый удалённому серверу для выполнения, можно изучить с помощью команды EXPLAIN VERBOSE
.
F.54.5. Окружение удалённого выполнения запросов
В удалённых сеансах, установленных обёрткой postgres_fdw
, в параметре search_path задаётся только pg_catalog
, так что без указания схемы видны только встроенные объекты. Это не проблема для запросов, которые генерирует сама postgres_fdw
, так как она всегда добавляет такие указания. Однако это может быть опасно для функций, которые выполняются на удалённом сервере при срабатывании триггеров или правил для удалённых таблиц. Например, если удалённая таблица на самом деле представляет собой представление, любые функции, используемые в этом представлении, будут выполняться с таким ограниченным путём поиска. Поэтому рекомендуется в таких функциях дополнять схемой все имена либо добавлять параметры SET search_path
(см. CREATE FUNCTION) в определения таких функций, чтобы установить ожидаемый ими путь поиска в окружении.
Обёртка postgres_fdw
подобным образом устанавливает для удалённого сеанса различные параметры:
TimeZone —
UTC
DateStyle —
ISO
IntervalStyle —
postgres
extra_float_digits принимает значение
3
для удалённых серверов версии 9.0 и новее либо2
для более старых версий
С ними проблемы менее вероятны, чем с search_path
, но если они возникнут, их можно урегулировать, установив нужные значения с помощью SET
.
Это поведение не рекомендуется переопределять, устанавливая значения этих параметров на уровне сеанса; это скорее всего приведёт к поломке postgres_fdw
.
F.54.6. Совместимость с разными версиями
Модуль postgres_fdw
может применяться с удалёнными серверами версий, начиная с PostgreSQL 8.3. Способность только чтения данных доступна, начиная с 8.1. Однако при этом есть ограничение, вызванное тем, что postgres_fdw
полагает, что постоянные встроенные функции и операторы могут безопасно передаваться на удалённый сервер для выполнения, если они фигурируют в предложении WHERE
для сторонней таблицы. Таким образом, встроенная функция, добавленная в более новой версии, чем на удалённом сервере, может быть отправлена на выполнение, что в результате приведёт к ошибке «функция не существует» или подобной. Отказы такого типа можно предотвратить, переписав запрос, например, поместив ссылку на стороннюю таблицу во вложенный SELECT
с OFFSET 0
в качестве защиты от оптимизации, и применив проблематичную функцию или оператор снаружи этого вложенного SELECT
.
F.54.7. Примеры
Ниже приведён пример создания сторонней таблицы с применением postgres_fdw
. Сначала установите расширение:
CREATE EXTENSION postgres_fdw;
Затем создайте сторонний сервер с помощью команды CREATE SERVER. В данном примере мы хотим подключиться к серверу Postgres Pro, работающему по адресу 192.83.123.89
, порт 5432
. База данных, к которой устанавливается подключение, на удалённом сервере называется foreign_db
:
CREATE SERVER foreign_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '192.83.123.89', port '5432', dbname 'foreign_db');
Для определения роли, которая будет задействована на удалённом сервере, с помощью CREATE USER MAPPING задаётся сопоставление пользователей:
CREATE USER MAPPING FOR local_user SERVER foreign_server OPTIONS (user 'foreign_user', password 'password');
Теперь можно создать стороннюю таблицу, применив команду CREATE FOREIGN TABLE. В этом примере мы хотим обратиться к таблице some_schema.some_table
на удалённом сервере. Локальным именем этой таблицы будет foreign_table
:
CREATE FOREIGN TABLE foreign_table ( id integer NOT NULL, data text ) SERVER foreign_server OPTIONS (schema_name 'some_schema', table_name 'some_table');
Важно, чтобы типы данных и другие свойства столбцов, объявленных в CREATE FOREIGN TABLE
, соответствовали фактической удалённой таблице. Также должны соответствовать имена столбцов, если только вы не добавите параметры column_name
для отдельных столбцов, задающие их реальные имена в удалённой таблице. Во многих случаях использовать IMPORT FOREIGN SCHEMA предпочтительнее, чем конструировать определения сторонних таблиц вручную.
34.10. Functions Associated with the COPY
Command
The COPY
command in PostgreSQL has options to read from or write to the network connection used by libpq. The functions described in this section allow applications to take advantage of this capability by supplying or consuming copied data.
The overall process is that the application first issues the SQL COPY
command via PQexec
or one of the equivalent functions. The response to this (if there is no error in the command) will be a PGresult
object bearing a status code of PGRES_COPY_OUT
or PGRES_COPY_IN
(depending on the specified copy direction). The application should then use the functions of this section to receive or transmit data rows. When the data transfer is complete, another PGresult
object is returned to indicate success or failure of the transfer. Its status will be PGRES_COMMAND_OK
for success or PGRES_FATAL_ERROR
if some problem was encountered. At this point further SQL commands can be issued via PQexec
. (It is not possible to execute other SQL commands using the same connection while the COPY
operation is in progress.)
If a COPY
command is issued via PQexec
in a string that could contain additional commands, the application must continue fetching results via PQgetResult
after completing the COPY
sequence. Only when PQgetResult
returns NULL
is it certain that the PQexec
command string is done and it is safe to issue more commands.
The functions of this section should be executed only after obtaining a result status of PGRES_COPY_OUT
or PGRES_COPY_IN
from PQexec
or PQgetResult
.
A PGresult
object bearing one of these status values carries some additional data about the COPY
operation that is starting. This additional data is available using functions that are also used in connection with query results:
PQnfields
Returns the number of columns (fields) to be copied.
PQbinaryTuples
0 indicates the overall copy format is textual (rows separated by newlines, columns separated by separator characters, etc). 1 indicates the overall copy format is binary. See COPY for more information.
PQfformat
Returns the format code (0 for text, 1 for binary) associated with each column of the copy operation. The per-column format codes will always be zero when the overall copy format is textual, but the binary format can support both text and binary columns. (However, as of the current implementation of
COPY
, only binary columns appear in a binary copy; so the per-column formats always match the overall format at present.)
34.10.1. Functions for Sending COPY
Data
These functions are used to send data during COPY FROM STDIN
. They will fail if called when the connection is not in COPY_IN
state.
PQputCopyData
Sends data to the server during
COPY_IN
state.int PQputCopyData(PGconn *conn, const char *buffer, int nbytes);
Transmits the
COPY
data in the specifiedbuffer
, of lengthnbytes
, to the server. The result is 1 if the data was queued, zero if it was not queued because of full buffers (this will only happen in nonblocking mode), or -1 if an error occurred. (UsePQerrorMessage
to retrieve details if the return value is -1. If the value is zero, wait for write-ready and try again.)The application can divide the
COPY
data stream into buffer loads of any convenient size. Buffer-load boundaries have no semantic significance when sending. The contents of the data stream must match the data format expected by theCOPY
command; see COPY for details.PQputCopyEnd
Sends end-of-data indication to the server during
COPY_IN
state.int PQputCopyEnd(PGconn *conn, const char *errormsg);
Ends the
COPY_IN
operation successfully iferrormsg
isNULL
. Iferrormsg
is notNULL
then theCOPY
is forced to fail, with the string pointed to byerrormsg
used as the error message. (One should not assume that this exact error message will come back from the server, however, as the server might have already failed theCOPY
for its own reasons.)The result is 1 if the termination message was sent; or in nonblocking mode, this may only indicate that the termination message was successfully queued. (In nonblocking mode, to be certain that the data has been sent, you should next wait for write-ready and call
PQflush
, repeating until it returns zero.) Zero indicates that the function could not queue the termination message because of full buffers; this will only happen in nonblocking mode. (In this case, wait for write-ready and try thePQputCopyEnd
call again.) If a hard error occurs, -1 is returned; you can usePQerrorMessage
to retrieve details.After successfully calling
PQputCopyEnd
, callPQgetResult
to obtain the final result status of theCOPY
command. One can wait for this result to be available in the usual way. Then return to normal operation.
34.10.2. Functions for Receiving COPY
Data
These functions are used to receive data during COPY TO STDOUT
. They will fail if called when the connection is not in COPY_OUT
state.
PQgetCopyData
Receives data from the server during
COPY_OUT
state.int PQgetCopyData(PGconn *conn, char **buffer, int async);
Attempts to obtain another row of data from the server during a
COPY
. Data is always returned one data row at a time; if only a partial row is available, it is not returned. Successful return of a data row involves allocating a chunk of memory to hold the data. Thebuffer
parameter must be non-NULL
.*buffer
is set to point to the allocated memory, or toNULL
in cases where no buffer is returned. A non-NULL
result buffer should be freed usingPQfreemem
when no longer needed.When a row is successfully returned, the return value is the number of data bytes in the row (this will always be greater than zero). The returned string is always null-terminated, though this is probably only useful for textual
COPY
. A result of zero indicates that theCOPY
is still in progress, but no row is yet available (this is only possible whenasync
is true). A result of -1 indicates that theCOPY
is done. A result of -2 indicates that an error occurred (consultPQerrorMessage
for the reason).When
async
is true (not zero),PQgetCopyData
will not block waiting for input; it will return zero if theCOPY
is still in progress but no complete row is available. (In this case wait for read-ready and then callPQconsumeInput
before callingPQgetCopyData
again.) Whenasync
is false (zero),PQgetCopyData
will block until data is available or the operation completes.After
PQgetCopyData
returns -1, callPQgetResult
to obtain the final result status of theCOPY
command. One can wait for this result to be available in the usual way. Then return to normal operation.
34.10.3. Obsolete Functions for COPY
These functions represent older methods of handling COPY
. Although they still work, they are deprecated due to poor error handling, inconvenient methods of detecting end-of-data, and lack of support for binary or nonblocking transfers.
PQgetline
Reads a newline-terminated line of characters (transmitted by the server) into a buffer string of size
length
.int PQgetline(PGconn *conn, char *buffer, int length);
This function copies up to
length
-1 characters into the buffer and converts the terminating newline into a zero byte.PQgetline
returnsEOF
at the end of input, 0 if the entire line has been read, and 1 if the buffer is full but the terminating newline has not yet been read.Note that the application must check to see if a new line consists of the two characters
\.
, which indicates that the server has finished sending the results of theCOPY
command. If the application might receive lines that are more thanlength
-1 characters long, care is needed to be sure it recognizes the\.
line correctly (and does not, for example, mistake the end of a long data line for a terminator line).PQgetlineAsync
Reads a row of
COPY
data (transmitted by the server) into a buffer without blocking.int PQgetlineAsync(PGconn *conn, char *buffer, int bufsize);
This function is similar to
PQgetline
, but it can be used by applications that must readCOPY
data asynchronously, that is, without blocking. Having issued theCOPY
command and gotten aPGRES_COPY_OUT
response, the application should callPQconsumeInput
andPQgetlineAsync
until the end-of-data signal is detected.Unlike
PQgetline
, this function takes responsibility for detecting end-of-data.On each call,
PQgetlineAsync
will return data if a complete data row is available in libpq's input buffer. Otherwise, no data is returned until the rest of the row arrives. The function returns -1 if the end-of-copy-data marker has been recognized, or 0 if no data is available, or a positive number giving the number of bytes of data returned. If -1 is returned, the caller must next callPQendcopy
, and then return to normal processing.The data returned will not extend beyond a data-row boundary. If possible a whole row will be returned at one time. But if the buffer offered by the caller is too small to hold a row sent by the server, then a partial data row will be returned. With textual data this can be detected by testing whether the last returned byte is
\n
or not. (In a binaryCOPY
, actual parsing of theCOPY
data format will be needed to make the equivalent determination.) The returned string is not null-terminated. (If you want to add a terminating null, be sure to pass abufsize
one smaller than the room actually available.)PQputline
Sends a null-terminated string to the server. Returns 0 if OK and
EOF
if unable to send the string.int PQputline(PGconn *conn, const char *string);
The
COPY
data stream sent by a series of calls toPQputline
has the same format as that returned byPQgetlineAsync
, except that applications are not obliged to send exactly one data row perPQputline
call; it is okay to send a partial line or multiple lines per call.Note
Before PostgreSQL protocol 3.0, it was necessary for the application to explicitly send the two characters
\.
as a final line to indicate to the server that it had finished sendingCOPY
data. While this still works, it is deprecated and the special meaning of\.
can be expected to be removed in a future release. It is sufficient to callPQendcopy
after having sent the actual data.PQputnbytes
Sends a non-null-terminated string to the server. Returns 0 if OK and
EOF
if unable to send the string.int PQputnbytes(PGconn *conn, const char *buffer, int nbytes);
This is exactly like
PQputline
, except that the data buffer need not be null-terminated since the number of bytes to send is specified directly. Use this procedure when sending binary data.PQendcopy
Synchronizes with the server.
int PQendcopy(PGconn *conn);
This function waits until the server has finished the copying. It should either be issued when the last string has been sent to the server using
PQputline
or when the last string has been received from the server usingPQgetline
. It must be issued or the server will get “out of sync” with the client. Upon return from this function, the server is ready to receive the next SQL command. The return value is 0 on successful completion, nonzero otherwise. (UsePQerrorMessage
to retrieve details if the return value is nonzero.)When using
PQgetResult
, the application should respond to aPGRES_COPY_OUT
result by executingPQgetline
repeatedly, followed byPQendcopy
after the terminator line is seen. It should then return to thePQgetResult
loop untilPQgetResult
returns a null pointer. Similarly aPGRES_COPY_IN
result is processed by a series ofPQputline
calls followed byPQendcopy
, then return to thePQgetResult
loop. This arrangement will ensure that aCOPY
command embedded in a series of SQL commands will be executed correctly.Older applications are likely to submit a
COPY
viaPQexec
and assume that the transaction is done afterPQendcopy
. This will work correctly only if theCOPY
is the only SQL command in the command string.