Сводка изменений с момента запуска Протокола 2.0

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

В начальном стартовом пакете вместо фиксированного формата используется гибкий формат списка строк. Обратите внимание, что значения по умолчанию для параметров времени выполнения сессии теперь можно указывать непосредственно в стартовом пакете. (На самом деле это можно было делать и раньше, используя поле options, но, учитывая ограниченную ширину options и отсутствие возможности заключать в кавычки пробельные символы в значениях, это было не очень безопасно).

Все сообщения теперь имеют счетчик длины сразу после байта типа сообщения (за исключением стартовых пакетов, которые не имеют байта типа). Также обратите внимание, что PasswordMessage теперь имеет байт типа.

Сообщения ErrorResponse и NoticeResponse (E и N) теперь содержат несколько полей, из которых клиентский код может собрать сообщение об ошибке нужного уровня сложности. Обратите внимание, что отдельные поля обычно не заканчиваются новой строкой, в то время как в старом протоколе это всегда делала одна строка.

Сообщение ReadyForQuery (Z) содержит индикатор состояния транзакции.

Различия между типами сообщений BinaryRow и DataRow исчезли; единый тип сообщения DataRow служит для возврата данных во всех форматах. Обратите внимание, что макет DataRow изменился, чтобы его было легче разбирать. Также изменилось представление двоичных значений: оно больше не привязано напрямую к внутреннему представлению сервера.

Существует новый подпротокол "расширенный запрос", который добавляет фронтэндные типы сообщений Parse, Bind, Execute, Describe, Close, Flush и Sync, а также бэкэндные типы сообщений ParseComplete, BindCom- plete, PortalSuspended, ParameterDescription, NoData и CloseComplete. Существующим клиентам не обязательно иметь дело с этим подпротоколом, но его использование может позволить улучшить производительность или функциональность.

Данные COPY теперь инкапсулируются в сообщения CopyData и CopyDone. Существует четко определенный способ восстановления после ошибок во время COPY. Специальная последняя строка \. больше не нужна и не передается при COPY OUT. (Она все еще распознается как терминатор при COPY IN, но ее использование устарело и со временем будет удалено). Поддерживается бинарное копирование. Сообщения CopyInResponse и CopyOutResponse включают поля, указывающие количество столбцов и формат каждого столбца.

Изменилось оформление сообщений FunctionCall и FunctionCallResponse. FunctionCall теперь может поддерживать передачу NULL-аргументов в функции. Он также может передавать параметры и получать результаты в текстовом или двоичном формате. Больше нет причин считать FunctionCall потенциальной брешью в безопасности, поскольку он не предоставляет прямого доступа к внутренним представлениям данных сервера.

Бэкэнд отправляет сообщения ParameterStatus (S) при запуске соединения для всех параметров, которые он считает интересными для клиентской библиотеки. В дальнейшем сообщение ParameterStatus отправляется при изменении активного значения любого из этих параметров.

Сообщение RowDescription (T) содержит новые поля OID таблицы и номера столбцов для каждого столбца описываемой строки. Оно также показывает код формата для каждого столбца.

Сообщение CursorResponse (P) больше не генерируется бэкендом.

Сообщение NotificationResponse (A) имеет дополнительное строковое поле, которое может содержать строку "полезной нагрузки", переданную отправителем события NOTIFY.

Сообщение EmptyQueryResponse (I) раньше включало параметр пустой строки; это было удалено.