Esta seccion describe el formato detallado de cada mensaje. Cana uno puede ser enviado por un frontend (F), por un backend (B) o por ambos (F y B).
Identifica el mensaje como una fila de datos ASCII . (Un mensaje previo RowDescription define el n�mero de campos en la fila y sus tipos de datos).
Un mapa de bits con un bit para cada campo en la fila. El primer campo corresponde al bit 7 (MSB) del primer byte, el segundo campo corresponde al bit 6 del primer byte, el octavo campo corresponde al bit 0 (LSB) del primer byte, el noveno campo corresponde al bit 7 del segundo byte, y as� sucesivamente. Cada bit est� activo si el valor del campo correspondiente no es NULL. Si el n�mero de campos no es un m�ltiplo de 8, el resto del �ltimo byte en el mapa de bits no es utilizado.
Por lo tanto, para cada campo con un valor no NULL, tenemos lo siguiente:
Especifica el tama�o del valor del campo, incluyendo este tama�o.
Especifica el valor del campo mismo en caracteres ASCII. n es el anterior tama�o menos 4. No hay '\0' al final del campo de datos, el frontend debe a�adirlo si quiere uno.
Identifica el mensaje como una petici�n de autentificaci�n.
Especifica que la autentificaci�n tuvo �xito.
Identifica el mensaje como una petici�n de autentificaci�n.
Especifica que se requiere autentificaci�n Kerberos V4.
Identifica el mensaje como una petici�n de autentificaci�n.
Especifica que se requiere autentificaci�n Kerberos V5.
Identifica el mensaje como una petici�n de autentificaci�n.
Especifica que se requiere una contrase�a no encriptada.
Identifica el mensaje como una petici�n de autentificaci�n.
Especifica que se requiere una contrase�a encriptada.
El salto a utilizar al encriptar la contrase�a.
Identifica el mensaje como una clave de cancelaci�n. El frontend debe guardar estos valore se desea poder enviar mensajes CancelRequest posteriormente.
El ID de proceso del backend.
La clave secreta de este backend.
Identifica el mensaje como una fila de datos binarios. (Un mensaje RowDescription previo define el n�mero de campos en la fial y sus tipos de datos)
Un mapa de bits con un bit para cada campo en la fila. El primer campo corresponde al bit 7 (MSB) del primer byte, el segundo campo corresponde al bit 6 del primer byte, el octavo campo corresponde al bit 0 (LSB) del primer byte, el noveno campo corresponde al bit 7 del segundo byte, y as� sucesivamente. Cada bit est� activo si el valor del campo correspondiente no es NULL. Si el n�mero de campos no es un m�ltiplo de 8, el resto del �ltimo byte en el mapa de bits no es utilizado.
Para cada campo con un valor distinto de NULL, tenemos lo siguiente:
Especifica el tama�o del valor del campo, excluyendo este tama�o. **************************************************************************** *************************** Comprobar esto, por que aqu� dice _excluyendo_ y antes (l�nea 756) dice incluyendo??????????????***************** ****************************************************************************
Especifica el valor del campo mismo en formato binario. n es el tama�o previo.
El tama�o del paquete en bytes.
El c�digo de cancelaci�n de petici�n. El valor es elegido para que contenga "1234" el los 16 bits m�s significativos, y "5678" en los 16 bits menos significativos. Para evitar confisi�n, este c�digo no debe ser el mismo que ning�n n�mero de versi�n del protocolo.
El ID de proceso del backend objetivo.
La clave secreta para el backend objectivo.
Identifica este mensaje como una petici�n completada.
El comando. Normalmente (pero no siempre) una palabra simple que identifica que comando SQL se complet�.
Es un flujo de filas donde cada una est� terminada por un Byte1('\n'). Se completa con una secuencia Byte1('\\'), Byte1('.'), Byte1('\n').
Identifica el mensaje como una respuesta Start Copy In. El frontend debe enviar un mensaje CopyDataRows.
Identifica el mensaje como una respuesta Start Copy Out. Este mensaje ser� seguido por un mensaje CopyDataRows.
Identifica el mensaje como un cursor.
El nombre del cursor. Ser� "blanco" si el cursor es impl�cito.
Identifica este mensaje como una respuesta a una sentencia vac�a.
Sin utilizar.
El tama�o del paquete en bytes.
La contrase�a encriptada (mediante crypt()).
Identifica el mensaje como un error.
El mensaje de error mismo.
Identifica el mensaje como una llamada a funci�n.
Sin utilizar.
Especifica el ID de objeto de la funci�n a llamar.
Especifica el n�mero de argumentos que se suministran a la funci�n.
Para cada argumento, se tiene lo siguiente:
Especifica el tama�o del valor del argumento, excluyendo este tama�o.
Especifica el valor del campo mismo en formato binario. n es el tama�o anterior.
Identifica el mensaje como un resultado de llamada a funci�n.
Especifica que se devolvi� un resultado no vac�o.
Especifica el tama�o del valor del resultado, excluyendo este tama�o.
Especifia el valor del resultado en formato binario. n Es el tama�o anterior.
Sin utilizar. (Hablando propiamente, FunctionResultResponse y FunctionVoidResponse son lo mismo pero con algunas partes opcionales en el mensaje).
Identifica el mensaje como un resultado de llamada a funci�n.
Especifica que se devolvi� un resultado vac�o.
Identifica el mensaje como una advertencia.
El mensaje de advertencia mismo.
Identifica el mansaje como una repuesta de notificaci�n.
El ID de proceso del proceso backend.
El nombre de la condici�n en la que se lanz� la notificaci�n.
Identifica el mensaje como una petici�n.
La petici�n misma.
Identifica el tipo de mensaje. ReadyForQuery es enviado cuando el backend est� listo para un nuevo ciclo de petici�n.
Identifica el mensaje como una descripci�n de fila.
Especifica el n�mero de campos en una fila (puede ser cero).
Para cada campo tenemos lo siguiente:
Especifica el nombre del campo.
Especifica el ID de objeto del tipo de campo.
Especifica el tama�o del tipo.
Especifica el modificador del tipo.
El tama�o del paquete en bytes.
El n�mero de versi�n del protocolo. Los 16 bits m�s significativos son el numero de versi�n mayor. Los 16 bits menos significativos son el n�mero de versi�n menor.
El nombre de la base de datos, por defecto el nombre del usuario si no se especifica.
El nombre del usuario.
Cualquier linea de argumentos para pasar al backend por el postmaster.
Sin utilizar.
La tty opcional que el backen deber�a utilizar para mensajes de depuraci�n.
Identifica el mensaje como una terminaci�n.
El tama�o del paquete en bytes.
La contrase�a sin encriptar.