53.10. Сводка изменений с протокола 2.0#
53.10. Сводка изменений с протокола 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, BindComplete, PortalSuspended, ParameterDescription, NoData и CloseComplete для сервера. Существующим клиентам не нужно беспокоиться о данном подпротоколе, но его использование может привести к улучшению производительности или функциональности.
Все данные COPY теперь инкапсулированы в сообщения CopyData и CopyDone. Существует четко определенный способ восстановления после ошибок во время COPY. Специальная последняя строка “\.” больше не нужна и не отправляется во время COPY OUT. (Она все еще распознается как завершающий символ во время COPY IN, но ее использование устарело и в конечном итоге будет удалено). Поддерживается двоичный COPY. Сообщения CopyInResponse и CopyOutResponse включают поля, указывающие количество столбцов и формат каждого столбца.
Изменилась структура сообщений FunctionCall и FunctionCallResponse. Теперь FunctionCall может поддерживать передачу NULL-аргументов функциям. Он также может обрабатывать передачу параметров и получение результатов в текстовом или двоичном формате. Больше нет причин считать FunctionCall потенциальной уязвимостью безопасности, так как он не предоставляет прямого доступа к внутренним представлениям данных сервера.
Бэкенд отправляет сообщения ParameterStatus ('S') во время установления соединения для всех параметров, которые он считает интересными для клиентской библиотеки. В дальнейшем, сообщение ParameterStatus отправляется каждый раз, когда активное значение изменяется для любого из этих параметров.
Сообщение RowDescription ('T') содержит новый идентификатор таблицы и номер столбца для каждого столбца описанной строки. Оно также показывает код формата для каждого столбца.
Сообщение CursorResponse ('P') больше не генерируется сервером.
У сообщения NotificationResponse ('A') есть дополнительное строковое поле, которое может содержать строку “payload”, переданную от отправителя события NOTIFY.
Сообщение EmptyQueryResponse ('I') ранее включало пустой
строковый параметр; он был удален.