Esta sección proporciona una lista rápida de cambios, para beneficio de los desarrolladores que intentan actualizar las bibliotecas cliente existentes al protocolo 3.0.

El paquete de inicio inicial utiliza un formato flexible de lista de cadenas en lugar de un formato fijo. Ten en cuenta que los valores predeterminados de sesión para los parámetros en tiempo de ejecución ahora se pueden especificar directamente en el paquete de inicio. (En realidad, podías hacer eso antes usando el campo options, pero debido al ancho limitado de options y a la falta de cualquier forma de entrecomillar los espacios en blanco en los valores, no era una técnica muy segura).

Todos los mensajes tienen ahora un recuento de longitud inmediatamente después del byte del tipo de mensaje (excepto para los paquetes de inicio, que no tienen byte de tipo). Ten en cuenta también que PasswordMessage ahora tiene un byte de tipo.

Los mensajes ErrorResponse y NoticeResponse ('E' y 'N') contienen ahora múltiples campos, a partir de los cuales el código cliente puede armar un mensaje de error con el nivel deseado de detalle. Ten en cuenta que los campos individuales típicamente no terminarán con un salto de línea, mientras que la única cadena enviada en el protocolo antiguo siempre lo hacía.

El mensaje ReadyForQuery ('Z') incluye un indicador de estado de transacción.

La distinción entre los tipos de mensajes BinaryRow and DataRow ha desaparecido; el único tipo de mensaje DataRow sirve para devolver datos en todos los formatos. Ten en cuenta que el diseño de DataRow ha cambiado para facilitar su análisis. Además, la representación de los valores binarios ha cambiado: ya no está directamente vinculada a la representación interna del servidor.

Existe un nuevo subprotocolo de “consulta extendida”, que agrega los tipos de mensajes de frontend Parse, Bind, Execute, Describe, Close, Flush y Sync, y los tipos de mensajes de backend ParseComplete, BindComplete, PortalSuspended, ParameterDescription, NoData y CloseComplete. Los clientes existentes no tienen que preocuparse por este subprotocolo, pero su uso podría permitir mejoras en el rendimiento o la funcionalidad.

Los datos de COPY ahora se encapsulan en mensajes CopyData y CopyDone. Existe una forma bien definida de recuperarse de los errores durante un COPY. La última línea especial “\.” ya no es necesaria y no se envía durante COPY OUT. (Todavía se reconoce como un terminador durante un COPY IN en modo texto, pero no en modo CSV. El comportamiento en modo texto está en desuso y eventualmente podría eliminarse). Se admite el COPY binario. Los mensajes CopyInResponse y CopyOutResponse incluyen campos que indican el número de columnas y el formato de cada columna.

El diseño de los mensajes FunctionCall y FunctionCallResponse ha cambiado. FunctionCall ahora puede admitir el paso de argumentos NULL a las funciones. También puede manejar el paso de parámetros y la recuperación de resultados en formato de texto o binario. Ya no hay ninguna razón para considerar a FunctionCall como un posible agujero de seguridad, ya que no ofrece acceso directo a las representaciones internas de datos del servidor.

El backend envía mensajes ParameterStatus ('S') durante el inicio de la conexión para todos los parámetros que considera interesantes para la biblioteca cliente. Posteriormente, se envía un mensaje ParameterStatus cada vez que cambia el valor activo para cualquiera de estos parámetros.

El mensaje RowDescription ('T') lleva nuevos campos de OID de tabla y número de columna para cada columna de la fila descrita. También muestra el código de formato para cada columna.

El backend ya no genera el mensaje CursorResponse ('P').

El mensaje NotificationResponse ('A') tiene un campo de cadena adicional, que puede llevar una cadena de carga útil (“payload”) pasada desde el remitente del evento NOTIFY.

El mensaje EmptyQueryResponse ('I') solía incluir un parámetro de cadena vacía; este ha sido eliminado.