Documentation PostgreSQL 8.0.2 | ||||
---|---|---|---|---|
Précédent | Arrière rapide | Chapitre 42. Protocole d'interface et de moteur | Avance rapide | Suivant |
Cette section fournit une liste rapide des modifications au bénéfice des développeurs essayant de mettre à jour les bibliothèques clients vers le protocole 3.0.
Le paquet de lancement initial utilise un format flexible de liste de chaînes au lieu d'un format fixe. Notez que les valeurs par défaut d'une session pour les paramètres en exécution peuvent même être spécifiés directement dans le paquet de lancement. (En fait, vous pouviez le faire avant en utilisant le champ options mais étant donné la largeur limitée d'options et le manque d'un autre moyen de mettre entre guillemets les espaces blancs dans les valeurs, la technique n'était pas très sûre.)
Tous les messages ont maintenant une longueur suivant immédiatement l'octet du type de message (sauf pour les paquets de lancement qui n'ont pas d'octet de type). Notez aussi que PasswordMessage a maintenant un octet de type.
Les messages ErrorResponse et NoticeResponse ('E' et 'N') contiennent maintenant plusieurs champs, à partir duquel le code client pourrait assembler un message d'erreur du niveau désiré de verbosité. Notez que des champs individuels ne se termineraient pas typiquement avec un retour chariot alors que la chaîne seule envoyée dans l'ancien protocole le faisait toujours.
Le message ReadyForQuery ('Z') inclut un indicateur de statut pour la transaction.
La distinction entre les types de messages BinaryRow et DataRow est finie ; le seul type de message DataRow sert pour les données renvoyées dans tous les formats. Notez que la disposition de DataRow a changé pour le rendre plus simple à analyser. Aussi, la représentation des valeurs binaires a changée : elle n'est plus liée directement à la représentation interne du serveur.
Il existe un nouveau sous-protocole pour les << requêtes étendues >> qui ajoute les types de messages client Parse, Bind, Execute, Describe, Close, Flush et Sync et les types de messages serveur ParseComplete, BindComplete, PortalSuspended, ParameterDescription, NoData et CloseComplete. Les clients existant ne concernent pas eux-mêmes avec ce sous-protocole mais son utilisation pourrait autoriser des améliorations en performance ou en fonctionnalité.
Les données de COPY sont maintenant encapsulées dans les messages CopyData et CopyDone. Il y a une façon bien définie de récupérer les erreurs lors du COPY. La dernière ligne spéciale << \. >> n'est plus nécessaire et n'est pas envoyée lors de COPY OUT. (C'est toujours reconnu comme un indicateur de fin lors du COPY IN mais son utilisation est obsolète et sera éventuellement supprimée.) Le COPY binaire est supporté. Les messages CopyInResponse et CopyOutResponse incluent les champs indiquant le nombre de colonnes et le format de chaque colonne.
La disposition des messages FunctionCall et FunctionCallResponse a changé. FunctionCall supporte maintenant le passage d'arguments NULL aux fonctions. Il peut aussi gérer le passage de paramètres et la récupération des résul tats soit au format texte soit au format binaire. Il n'y a plus aucune raison de considérer FunctionCall comme une faille potentielle de sécurité car il n'offre plus d'accès direct aux représentations internes des données du serveur.
Le serveur envoie des messages ParameterStatus ('S') lors du lancement de la connexion pour tous les paramètres qu'il considère int éressant pour la bibliothèque cliente. En conséquence, un message ParameterStatus est envoyé à chaque fois que la valeur active change pour n'importe quel paramètre.
Le message RowDescription ('T') emporte les nouveaux champs de l'OID de la table et le numéro de colonne pour chaque colonne de la ligne décrite. Il affiche aussi le code de format pour chaque colonne.
Le message CursorResponse ('P') n'est plus généré par le serveur.
Le message NotificationResponse ('A') a un champ de type chaîne supplémentaire, qui est actuellement vide mais pourrait transporter des données supplémentaires à partir du processus envoyant l'événement NOTIFY.
Le message EmptyQueryResponse ('I') utilisé pour inclure une paramètre de chaîne vide a été supprimé.
Précédent | Sommaire | Suivant |
Champs des messages d'erreur et d'avertissement | Niveau supérieur | Conventions de codage pour PostgreSQL |