Le protocole utilise des phases distinctes pour le lancement et le fonctionnement habituel. Dans la phase de lancement, le client ouvre une connexion au serveur et s'authentifie (ce qui peut impliquer un message simple, ou plusieurs messages, en fonction de la méthode d'authentification utilisée). En cas de réussite, le serveur envoie une information de statut au client et entre dans le mode normal de fonctionnement. Exception faite du message initial de demande de lancement, cette partie du protocole est conduite par le serveur.
En mode de fonctionnement normal, le client envoie requêtes et commandes au
serveur et celui-ci retourne les résultats de requêtes et autres réponses.
Il existe quelques cas (comme notify) pour lesquels le serveur
enverra des messages non sollicités. Mais dans l'ensemble, cette partie
de la session est conduite par les requêtes du client.
En général, c'est le client qui décide de la clôture de la session. Il arrive, cependant, qu'elle soit forcée par le moteur. Dans tous les cas, lors de la fermeture de la connexion par le serveur, toute transaction ouverte (non terminée) sera annulée.
En mode opérationnel normal, les commandes SQL peuvent être exécutées via deux sous-protocoles. Dans le protocole « Simple Query », le client envoie juste une chaîne, la requête, qui est analysée et exécutée immédiatement par le serveur. Dans le protocole « Extended Query », le traitement des requêtes est découpé en de nombreuses étapes : l'analyse, le lien avec les valeurs de paramètres et l'exécution. Ceci offre flexibilité et gains en performances au prix d'une complexité supplémentaire.
Le mode opérationnel normal offre des sous-protocoles supplémentaires pour
certaines opérations comme copy.
Toute la communication s'effectue au travers d'un flux de messages. Le premier octet d'un message identifie le type de message et les quatre octets suivants spécifient la longueur du reste du message (cette longueur inclut les 4 octets de longueur, mais pas l'octet du type de message). Le reste du contenu du message est déterminé par le type de message. Pour des raisons historiques, le tout premier message envoyé par le client (le message de lancement) n'a pas l'octet initial de type du message.
Pour éviter de perdre la synchronisation avec le flux de messages, le serveur et le client stockent le message complet dans un tampon (en utilisant le nombre d'octets) avant de tenter de traiter son contenu. Cela permet une récupération simple si une erreur est détectée lors du traitement du contenu. Dans les situations extrêmes (telles que de ne pas avoir assez de mémoire pour placer le message dans le tampon), le récepteur peut utiliser le nombre d'octets pour déterminer le nombre d'entrées à ignorer avant de continuer la lecture des messages.
En revanche, serveurs et clients doivent être attentifs à ne pas envoyer de message incomplet. Ceci est habituellement obtenu en plaçant le message complet dans un tampon avant de commencer l'envoi. Si un échec de communications survient pendant l'envoi ou la réception d'un message, la seule réponse plausible est l'abandon de la connexion. Il y a, en effet, peu d'espoir de resynchronisation des messages.
Dans le protocole Extended Query, l'exécution de commandes SQL est
scindée en plusieurs étapes. L'état retenu entre les étapes est représenté
par deux types d'objets : les instructions préparées et
les portails. Une instruction préparée représente le résultat
de l'analyse syntaxique et de l'analyse sémantique d'une
chaîne de requête textuelle. Une instruction préparée en elle-même n'est pas prête à
être exécutée parce qu'il peut lui manquer certaines valeurs de
paramètres. Un portail représente une instruction prête à être
exécutée ou déjà partiellement exécutée, dont toutes les valeurs de
paramètres manquants sont données (pour les instructions
select, un portail est équivalent à un curseur ouvert. Il est
choisi d'utiliser un terme différent, car les curseurs ne gèrent pas les
instructions autres que select).
Le cycle d'exécution complet consiste en une étape d'analyse syntaxique,
qui crée une instruction préparée à partir d'une chaîne de requête textuelle ;
une étape de liaison, qui crée un portail à partir d'une
instruction préparée et des valeurs pour les paramètres nécessaires ;
et une étape d'exécution qui exécute une requête du portail.
Dans le cas d'une requête qui renvoie des lignes (select,
show, etc), il peut être signalé à l'étape d'exécution
que seul un certain nombre de lignes doivent être retournées, de sorte que
de multiples étapes d'exécution seront nécessaires pour terminer l'opération.
Le serveur peut garder la trace de multiples instructions préparées et portails (qui n'existent qu'à l'intérieur d'une session, et ne sont jamais partagés entre les sessions). Les instructions préparées et les portails sont référencés par les noms qui leur sont affectés à la création. De plus, il existe une instruction préparée et un portail « non nommés ». Bien qu'ils se comportent comme des objets nommés, les opérations y sont optimisées en vue d'une exécution unique de la requête puis de son abandon. En revanche, les opérations sur les objets nommés sont optimisées pour des utilisations multiples.
Les données d'un type particulier peuvent être transmises sous différents formats. Depuis PostgreSQL 7.4, les seuls formats supportés sont le « texte » et le « binaire » mais le protocole prévoit des extensions futures. Le format souhaité pour toute valeur est spécifié par un code de format. Les clients peuvent spécifier un code de format pour chaque valeur de paramètre transmise et pour chaque colonne du résultat d'une requête. Une donnée de type texte a comme code de format zéro (0) et une donnée de type binaire a comme code de format un (1). Tous les autres codes de format sont réservés pour des définitions futures.
La représentation au format texte des valeurs est toute chaîne de caractères produite et acceptée par les fonctions de conversion en entrée/sortie pour le type de données particulier. Dans la représentation transmise, il n'y a pas de caractère nul de terminaison de chaîne ; le client doit en ajouter un aux valeurs reçues s'il souhaite les traiter comme des chaînes C (le format texte n'autorise pas les valeurs nulles intégrées).
Les représentations binaires des entiers utilisent l'ordre d'octet réseau (octet le plus significatif en premier). Pour les autres types de données, il faudra consulter la documentation ou le code source pour connaître la représentation binaire. Les représentations binaires des types de données complexes changent parfois entre les versions du serveur ; le format texte reste le choix le plus portable.
