44.6. R�sum� des modifications depuis le protocole 2.0

Cette section fournit une liste rapide des modifications � l'attention des d�veloppeurs essayant d'adapter au protocole 3.0 des biblioth�ques client existantes.

Le paquet de d�marrage initial utilise un format flexible de liste de cha�nes au lieu d'un format fixe. Les valeurs de session par d�faut des param�tres d'ex�cution peuvent m�me �tre sp�cifi�s directement dans le paquet de d�marrage. (En fait, cela �tait d�j� possible en utilisant le champ options ; mais �tant donn� la largeur limit�e d'options et l'impossibilit� de mettre entre guillemets les espaces fines dans les valeurs, ce n'�tait pas une technique tr�s s�re.)

Tous les messages poss�dent d�sormais une indication de longueur qui suit imm�diatement l'octet du type de message (sauf pour les paquets de d�marrage qui n'ont pas d'octet de type). PasswordMessage poss�de � pr�sent un octet de type.

Les messages ErrorResponse et NoticeResponse ('E' et 'N') contiennent maintenant plusieurs champs, � partir desquels le code client peut assembler un message d'erreur fonction du niveau de verbiage d�sir�. Des champs individuels ne se termineront plus par un retour chariot alors que la cha�ne seule envoy�e dans l'ancien protocole le faisait syst�matiquement.

Le message ReadyForQuery ('Z') inclut un indicateur d'�tat de la transaction.

La distinction entre les types de messages BinaryRow et DataRow est supprim�e ; le type de message DataRow seul sert � retourner les donn�es dans tous les formats. La disposition de DataRow a chang� pour faciliter son analyse. La repr�sentation des valeurs binaires a �galement �t� modifi�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 existants ne sont pas directement concern�s par ce sous-protocole, mais son utilisation apportera des am�liorations en terme de performances et de fonctionnalit�s.

Les donn�es de COPY sont d�sormais encapsul�es dans des messages CopyData et CopyDone. Il y a une fa�on bien d�finie de r�parer 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. (Elle est toujours reconnue comme un indicateur de fin lors du COPY IN mais son utilisation est obsol�te. Elle 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 � pr�sent le passage aux fonctions d'arguments NULL. Il peut aussi g�rer le passage de param�tres et la r�cup�ration de r�sultats aux formats texte et 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 de l'initialisation de la connexion pour tous les param�tres qu'il consid�re int�ressants pour la biblioth�que client. En cons�quence, un message ParameterStatus est envoy� � chaque fois que la valeur active d'un de ces param�tres change.

Le message RowDescription ('T') contient les nouveaux champs OID de table et de 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 engendr� par le serveur.

Le message NotificationResponse ('A') a un champ de type cha�ne suppl�mentaire, actuellement vide mais qui pourrait � terme transporter des donn�es suppl�mentaires engendr�es par l'�metteur de l'�v�nement NOTIFY.

Le message EmptyQueryResponse ('I') n�cessitait un param�tre cha�ne vide ; ce n'est plus le cas.