Протокол backend PostgreSQL: желаемые возможности

Текущий протокол документирован здесь: http://www.postgresql.org/docs/9.4/static/protocol.html

Выясняется, что он недостаточно полон, поэтому клиенты становятся более сложными, медленнее и т.д.

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

Возможности

Бинарная передача против точной типизации данных

Текущий протокол поддерживает текстовую и бинарную передачу. Оказывается, в текстовом режиме backend не нуждается в знании точного типа данных. В большинстве случаев он легко может вывести его. Бинарный режим обычно быстрее, однако при потреблении бинарных данных backend считает, что тип данных точно известен и не рассматривает преобразования.

Было бы здорово иметь возможность передавать значение в бинарном формате (для эффективности), но при этом заставлять backend выводить правильный тип данных для него.

Кевин Уоттен: моя самая большая просьба всегда заключается в том, чтобы относиться к бинарным типам как если бы клиент «знает» как с ними работать. Есть множество случаев с текстовым форматом, когда сервер будет принуждать столбцы к наиболее корректному типу, а это не происходит для бинарных запросов; он просто сообщает, что у вас неверный тип.И то, и другое — возможность переключиться на «предпочтение бинарного формата» в протоколе. Так что когда я делаю запрос без привязки, я могу получить результаты в бинарном формате. В настоящее время можно получать их только в текстовом формате. Это имеет несколько последствий. Во-первых, скорость, вы всегда должны связываться перед запросом, чтобы получить бинарные результаты. Во-вторых, множественные SQL-запросы в одном запросе, что невозможно сделать в привязанных запросах.### Нечеткие семантики чисел в текстовом режиме

В текстовом режиме числа и денежные типы передаются с неизвестным десятичным разделителем. Это затрудняет декодирование значения, так как это зависит от локали.

См.: https://github.com/pgjdbc/pgjdbc/pull/439

Отсутствие сообщений о том, что подготовленное заявление стало недействительным

Подготовленное заявление сервера может стать недействительным из-за изменения структуры таблицы, типа колонки и т. д. Это приводит к сообщению "ваши подготовленные заявления больше не действительны". Это не очень приятно.

См.: https://github.com/pgjdbc/pgjdbc/pull/451

Размышления### Алваро Хернандес — Одинаковые заголовки (тип байта). Некоторые сообщения (начало работы, SSL и т. д.) не имеют маркера типа байта.

Это неприятно.

• Передача типов байтов. Тип байта переиспользуется между отправителями и получателями. Это однозначно, но всё равно очень странно.
• Пайплайн запросов. Об этом много говорили. У меня нет чёткого вывода, кроме того, что это как-то возможно, но требует поддержки со стороны драйвера (отслеживание отправленных/полученных сообщений и ошибок). Это можно легко реализовать с помощью протокола, используя уникальный идентификатор для каждого сообщения и включая его в ответ.
• Поддержка кластеров. Реальные производственные среды являются кластерами (набором серверов PostgreSQL, использующих любую виду репликации). Протокол должен учитывать это, особенно если некоторые механизмы обеспечения высокой доступности встроены в протокол.
• Метаданные сервера без аутентификации. Некоторые сообщения должны иметь возможность обмениваться информацией о серверах (например, версию, состояние чтения/записи и, возможно, другие данные) без необходимости аутентификации и участия в длительных процессах.
• Отсутствие вне-канальных сообщений (например, отмены запроса)
• Упрощённый дизайн (текущий слишком сложен и имеет слишком много сообщений)- Описание в формальном синтаксисе (не английском, а формальном языке для спецификации) и наличие набора совместимости тестирования (TCK — Test Compatibility Kit)
• Разрешение некоторой контролируемой формы расширяемости протокола
• Метод обратной пропускной способности для результатов запросов
• Все «обычные подозреваемые»: поддержка двоичного формата, частичных результатов запросов, больших объектов и так далее

Владимир Ситников- сжатые данные через сеть

• сообщения типа "статус запроса ответа", отправляемые в обычном текстовом формате (insert 1, select 10 и т.д.) Наличие бинарной информации могло бы облегчить парсинг данных.
• невозможность использования подготовленных выражений для set "application_name"=... и т.д.