PostgreSQLLa base de données la plus sophistiquée au monde.

Recherche désactivée car pas de connexion à la base !

Documentation PostgreSQL 15.7 » Internes » Protocole Frontend/Backend » Champs des messages d'erreur et de notification

55.8. Champs des messages d'erreur et de notification

Cette section décrit les champs qui peuvent apparaître dans des messages ErrorResponse et NoticeResponse. Chaque type de champ a un jeton d'identification sur un seul octet. Notez que tout type de champ devrait apparaître au moins une fois par message.

S

Sévérité : le contenu du champ est ERROR, FATAL, ou PANIC (dans un message d'erreur), ou WARNING, NOTICE, DEBUG, INFO ou LOG (dans un message de notification), ou une traduction localisée d'un de ces messages. Toujours présent.

V

Sévérité : le contenu du champ est ERROR, FATAL, ou PANIC (dans un message d'erreur), ou WARNING, NOTICE, DEBUG, INFO, ou LOG (dans un message de notification). Ceci est identique au champ S sauf que son contenu n'est jamais localisé. Il est présent uniquement dans les messages générés par un serveur PostgreSQL en version 9.6 ou ultérieure.

C

Code : le code SQLSTATE pour l'erreur (voir Annexe A). Non localisable. Toujours présent.

M

Message : le message d'erreur principal, lisible par un humain. Il doit être précis mais court (typiquement une ligne). Toujours présent.

D

Détail : un message d'erreur secondaire et optionnel apportant plus d'informations sur le problème. Pourrait utiliser plusieurs lignes.

H

Astuce : une suggestion optionnelle pour corriger le problème. Ceci doit différer du Détail parce qu'il offre un conseil (potentiellement inapproprié) plutôt que des faits certains. Pourrait utiliser plusieurs lignes.

P

Position : la valeur du champ est un entier décimal ASCII, indiquant la position du curseur sur l'erreur comme un index sur la chaîne requête originale. Le premier caractère est à l'index 1, et les positions sont mesurés en caractères, et non pas en octets.

p

Position interne : ceci est défini de la même façon que le champ P, mais est utilisé quand la position du curseur fait référence à une commande générée en interne plutôt qu'une commande exécutée par le client. Le champ q apparaîtra toujours quand ce champ apparaît.

q

Requête interne : le texte d'une commande générée en interne. Cela pourrait être une requête SQL exécutée par une fonction PL/pgSQL par exemple.

W

Où : une indication du contexte dans lequel l'erreur s'est produite. Actuellement, cela inclut la pile d'appels des fonctions en langage procédural et les requêtes générées en interne. La trace est composée d'une entrée par ligne, la plus récente en premier.

s

Nom du schéma : si l'erreur était associée avec un objet particulier de la base, le nom du schéma contenant cet objet, s'il existe.

t

Nom de la table : si l'erreur était associée avec une table particulière, le nom de la table. (Référez-vous au champ du nom de schéma pour le nom du schéma de la table.)

c

Nom de la colonne : si l'erreur était associée à une colonne particulière de la table, le nom de la colonne. (Référez-vous aux champs de nom de schéma et de table pour identifier la table.)

d

Nom du type de données : si l'erreur était associée avec un type de données particulier, le nom du type de données. (Référez-vous au champ du nom de schéma pour le nom du schéma du type de données.)

n

Nom de contrainte : si l'erreur était associée avec une contrainte particulière, le nom de la contrainte. Référez-vous aux champs listées ci-dessus pour la table ou le domaine associé. (Dans ce but, les index sont traités comme des contraintes, même si elles n'ont pas été créées avec une syntaxe de contrainte.)

F

Fichier : le nom du fichier source où l'erreur a été rapportée.

L

Ligne : le numéro de ligne dans le fichier source où l'erreur a été rapportée.

R

Routine : le nom de la routine ayant rapportée l'erreur.

Note

Les champs du nom du schéma, de la table, de la colonne, du type de données et de la contrainte sont fournis seulement pour un nombre limité de types d'erreur ; voir Annexe A. Les clients ne doivent pas supposer que la présence d'un de ces champs garantie la présence d'un autre champ. Les sources des erreurs observent les relations notées ci-dessus, mais les fonctions définies par les utilisateurs pourraient utiliser ces champs d'une autre façon. Dans la même veine, les clients ne devraient pas supposer que ces champs parlent d'objets actuels dans la base actuelle.

Le client est responsable du formatage des informations affichées ; en particulier, il doit diviser les lignes longues si nécessaires. Les caractères de retour chariot apparaissant dans les champs du message d'erreur doivent être traités comme des changements de paragraphes, pas comme des changements de lignes.