Cette section fournit une liste rapide des changements, au bénéfice des développeurs essayant de mettre à jour leur bibliothèque client existante avec le protocole 3.0.

Le paquet de démarrage initial utilise un format flexible de liste de chaînes de caractères, au lieu d'un format fixé. Notez que les valeurs par défaut d'une session pour les paramètres d'exécution peuvent maintenant être spécifiées directement dans le paquet de démarrage. (En fait, vous pouvez le faire avant en utilisant le champ options mais, étant donné la largeur limité de ce champ et le manque de moyen pour mettre entre guillemets les espaces blancs dans les valeurs, ce n'était pas une technique très sûre.)

Tous les messages ont maintenant un compteur de longueur suivant immédiatement l'octet du type de message (sauf pour les paquets de démarrage qui n'ont pas d'octet de type). De plus, notez que le message PasswordMessage a maintenant un octet de type

Les messages ErrorResponse et NoticeResponse ('E' et 'N') contiennent maintenant plusieurs champs, à partir desquels le code du client peut assembler un message d'erreur avec le niveau de verbosité désiré. Notez que les champs individuels ne finiront habituellement pas avec un retour chariot, alors que la chaîne seule envoyée dans le protocole précédent le faisait toujours.

Le message ReadyForQuery ('Z') inclut un indicateur de statut de transaction.

La distinction entre les types de message BinaryRow et DataRow n'existe plus ; le type de message DataRow sert à renvoyer des données dans tous les formats. Notez que la disposition de DataRow a changé pour faciliter l'analyse. De plus, la représentation des valeurs binaires a changé : elle n'est plus directement liée à la représentation interne du serveur.

Il existe un nouveau sous-protocole de « requête étendue », qui ajoute les types de message client Parse, Bind, Execute, Describe, Close, Flush et Sync, ainsi que les types de message backend ParseComplete, BindComplete, PortalSuspended, ParameterDescription, NoData et CloseComplete. Les clients existants n'ont pas besoin de s'occuper de ce sous-protocole, mais l'utiliser pourrait permettre des améliorations en performance et en fonctionnalité.

Les données de COPY sont maintenant encapsulées dans des messages CopyData et CopyDone. Il existe une façon bien définie de reprendre après des erreurs survenues pendant un COPY. Le « \. » de la dernière ligne n'est plus nécessaire, et n'est plus envoyé lors d'un COPY OUT. (Il est toujours reconnu comme terminaison lors d'un COPY IN, mais son utilisation est abandonnée et finira par être supprimée.) Le COPY binaire est supporté. Les messages CopyInResponse et CopyOutResponse incluent des champs indiquant le nombre de colonnes et le format de chaque colonne.

La disposition des messages FunctionCall et FunctionCallResponse a changé. FunctionCall accepte maintenant de passer des arguments NULL aux fonctions. Il peut aussi gérer de passer des paramètres et de récupérer des résultats au format texte ou binaire. Il n'y a plus de raison de considérer FunctionCall comme une faille potentielle de sécurité car il n'offre pas d'accès direct aux représentations internes des données du serveur.

Le backend envoie des messages ParameterStatus ('S') lors du démarrage de la connexion pour tous les paramètres qu'il considère intéressant pour la bibliothèque cliente. De plus, un message ParameterStatus est envoyé à chaque fois que la valeur active est modifiée pour chacun de ces paramètres.

Le message RowDescription ('T') apporte de nouveaux champs pour l'OID de la table et le numéro de la colonne pour chaque colonne de la ligne décrite. Il affiche aussi le code format pour chaque colonne.

Le message CursorResponse ('P') n'est plus généré par le backend.

Le message NotificationResponse ('A') a un champ supplémentaire de type chaîne de caractères, qui peut porter une « charge » passé depuis l'événement NOTIFY.

Le message EmptyQueryResponse ('I') incluait un paramètre de chaîne vide ; il a été supprimé.