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

Version anglaise

51.6. Champs des messages d'erreur et d'avertissement

Cette section décrit les champs qui peuvent apparaître dans les messages ErrorResponse et NoticeResponse. Chaque type de champ a un motif d'identification codé sur un octet. Tout type de champ donné doit apparaître au plus une fois par message.

s

Gravité (Severity) : le contenu du champ peut être error, fatal ou panic dans un message d'erreur, warning, notice, debug, info ou log dans un message d'avertissement, ou la traduction régionale de l'un d'eux. Toujours présent.

V

Gravité : le contenu du champ peut être ERROR, FATAL ou PANIC (dans un message d'erreur), ou WARNING, NOTICE, DEBUG, INFO ou LOG (dans un message de notification). C'est identique au champ S sauf que le contenu n'est jamais traduit. C'est présent uniquement dans les rapports générés par les versions 9.6 et ultérieurs de PostgreSQL™.

c

Code : code SQLSTATE de l'erreur (voir Annexe A, Codes d'erreurs de PostgreSQL). non internationalisable. Toujours présent.

m

Message : premier message d'erreur, en clair. Doit être court et précis (typiquement une ligne). Toujours présent.

d

Détail : deuxième message d'erreur, optionnel, apportant des informations supplémentaires sur le problème. Peut être sur plusieurs lignes.

h

Astuce (Hint) : suggestion optionnelle de résolution du problème. Différent de Détail parce qu'il offre un conseil (potentiellement inapproprié) plutôt que des faits réels. Peut être sur plusieurs lignes.

p

Position : valeur du champ, entier décimal ASCII indiquant un curseur sur la position de l'erreur dans la chaîne de requête originale. Le premier caractère a l'index 1. Les positions sont mesurées en caractères, non pas en octets.

p

Position interne : ceci est défini de la même façon que le champ p mais c'est utilisé quand la position du curseur se réfère à une commande générée en interne plutôt qu'une soumise 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 et qui a échoué. Ceci pourrait être, par exemple, une requête SQL lancée par une fonction PL/pgSQL.

w

Où (Where) : indication du contexte dans lequel l'erreur est survenue. Inclut, actuellement, une trace de la pile des appels des fonctions PL actives. Cette trace comprend une entrée par ligne, la plus récente en premier.

s

Nom du schéma : si l'erreur est associée à un objet spécifique de la base de données, le nom du schéma contenant cet objet.

t

Nom de la table : si l'erreur est associée à une table spécifique, le nom de la table. (Fait référence au champ du nom du schéma pour le nom du schéma de la table.)

c

Nom de la colonne : si l'erreur est associée à une colonne spécifique, le nom de la colonne. (Fait référence aux champs des noms de schéma et de table pour identifier la table.)

d

Nom du type de données : si l'erreur est associée à un type de données spécifique, le nom du type de données. (Fait référence au champ du nom du schéma pour le nom du schéma du type de données.)

n

Nom de la contrainte : si l'erreur est associée à une contrainte spécifique, le nom de la contrainte. Cela fait référence aux champs listés ci-dessus pour la table ou le domaine associé. (Dans ce cadre, les index sont traités comme des contraintes même s'ils ont été créés autrement qu'avec la syntaxe des contraintes.)

F

Fichier (File) : nom du fichier de code source comportant l'erreur.

L

Ligne (Line) : numéro de ligne dans le fichier de code source comportant l'erreur.

R

Routine : nom de la routine dans le code source comportant l'erreur.

[Note]

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, Codes d'erreurs de PostgreSQL. Les clients ne devraient pas supposer que la présence d'un de ces champs garantisse la présence d'un autre champs. Le moteur observe les relations notées ci-dessus mais les fonctions utilisateurs peuvent utiliser ces champs d'autres façons. Dans la même veine, les clients ne doivent pas supposer que ces champs indiquent des objets actuels dans la base de données courante.

Le client est responsable du formatage adapté à ses besoins des informations affichées ; en particulier par l'ajout de retours chariots sur les lignes longues, si cela s'avérait nécessaire. Les caractères de retour chariot apparaissant dans les champs de messages d'erreur devraient être traités comme des changements de paragraphes, non comme des changements de lignes.