Cette variable précise l'ordre dans lequel les schémas sont parcourus lorsqu'un objet (table, type de données, fonction, etc.) est référencé par un simple nom sans précision du schéma. Lorsque des objets de noms identiques existent dans plusieurs schémas, c'est le premier trouvé dans le chemin de recherche qui est utilisé. Il ne peut être fait référence à un objet qui ne fait partie d'aucun des schémas indiqués dans le chemin de recherche qu'en précisant son schéma conteneur avec un nom qualifié (avec un point).
search_path doit contenir une liste de noms de schémas séparés par des virgules. Si un des éléments de la liste est la valeur spéciale $user, alors le schéma dont le nom correspond à la valeur retournée par SESSION_USER est substitué, s'il existe (sinon $user est ignoré).
Le schéma du catalogue système, pg_catalog, est toujours parcouru, qu'il soit ou non mentionné dans le chemin. Mentionné, il est alors parcouru dans l'ordre indiqué. Dans le cas contraire, il est parcouru avant tout autre élément du chemin.
De même, le schéma des tables temporaires, pg_temp_nnn, s'il existe, est toujours parcouru. Il peut être explicitement ajouté au chemin à l'aide de l'alias pg_temp. S'il n'en fait pas partie, la recherche commence par lui (avant même pg_catalog). Néanmoins, seuls les noms de relation (table, vue, séquence, etc.) et de type de données sont recherchés dans le schéma temporaire. Aucune fonction et aucun opérateur n'y est jamais recherché.
Lorsque des objets sont créés sans précision de schéma cible particulier, ils sont placés dans le premier schéma listé dans le chemin de recherche. Une erreur est rapportée si le chemin de recherche est vide.
La valeur par défaut de ce paramètre est '"$user", public' (la deuxième partie est ignorée s'il n'existe pas de schéma nommé public). Elle permet l'utilisation partagée d'une base de données (dans laquelle aucun utilisateur n'a de schéma privé et tous partagent l'utilisation de public), les schémas privés d'utilisateur ainsi qu'une combinaison de ces deux modes. D'autres effets peuvent être obtenus en modifiant le chemin de recherche par défaut, globalement ou par utilisateur.
La valeur courante réelle du chemin de recherche peut être examinée via la fonction SQL current_schemas() (voir Section 9.23, « Fonctions d'informations système »). Elle n'est pas identique à la valeur de search_path car current_schemas affiche la façon dont les requêtes apparaissant dans search_path sont résolues.
Pour plus d'informations sur la gestion des schémas, voir la Section 5.7, « Schémas ».
Cette variable indique le tablespace par défaut dans lequel sont créés les objets (tables et index) quand une commande CREATE ne l'explicite pas.
La valeur est soit le nom d'un tablespace soit une chaîne vide pour indiquer l'utilisation du tablespace par défaut de la base de données courante. Si la valeur ne correspond pas au nom d'un tablespace existant, PostgreSQL™ utilise automatiquement le tablespace par défaut de la base de données courante. Si un tablespace différent de celui par défaut est indiqué, l'utilisateur doit avoir le droit CREATE. Dans le cas contraire, la tentative de création échouera.
Cette variable n'est pas utilisée pour les tables temporaires ; pour elles, temp_tablespaces est consulté à la place.
Cette variable n'est pas utilisée non plus lors de la création de bases de données. Par défaut, une nouvelle base de données hérite sa configuration de tablespace de la base de données modèle qui sert de copie.
Pour plus d'informations sur les tablespaces, voir Section 21.6, « Tablespaces ».
Cette variable indique le (ou les) tablespace(s) dans le(s)quel(s) créer les objets temporaires (tables temporaires et index sur des tables temporaires) quand une commande CREATE n'en explicite pas. Les fichiers temporaires créés par les tris de gros ensembles de données sont aussi créés dans ce tablespace.
Cette valeur est une liste de noms de tablespaces. Quand cette liste contient plus d'un nom, PostgreSQL™ choisit un membre de la liste au hasard à chaque fois qu'un objet temporaire doit être créé. En revanche, dans une transaction, les objets temporaires créés successivement sont placés dans les tablespaces successifs de la liste. Si l'élément sélectionné de la liste est une chaîne vide, PostgreSQL™ utilise automatiquement le tablespace par défaut de la base en cours.
Si temp_tablespaces est configuré interactivement, l'indication d'un tablespace inexistant est une erreur. Il en est de même si l'utilisateur n'a pas le droit CREATE sur le tablespace indiqué. Néanmoins, lors de l'utilisation d'une valeur précédemment configurée, les tablespaces qui n'existent pas sont ignorés comme le sont les tablespaces pour lesquels l'utilisateur n'a pas le droit CREATE. Cette règle s'applique, en particulier, lors de l'utilisation d'une valeur configurée dans le fichier postgresql.conf.
La valeur par défaut est une chaîne vide. De ce fait, tous les objets temporaires sont créés dans le tablespace par défaut de la base de données courante.
Voir aussi default_tablespace.
Ce paramètre est habituellement positionné à on. Positionné à off, il désactive la validation du corps de la fonction lors de ???. Désactiver la validation évite les effets de bord du processus de validation et évite les faux positifs dûs aux problèmes, par exemple les références. Configurer ce paramètre à off avant de charger les fonctions à la place des autres utilisateurs ; pg_dump le fait automatiquement.
Chaque transaction SQL a un niveau d'isolation. Celui-ci peut être « read uncommitted », « read committed », « repeatable read » ou « serializable ». Ce paramètre contrôle le niveau d'isolation par défaut de chaque nouvelle transaction. La valeur par défaut est « read committed ».
Consulter le Chapitre 13, Contrôle d'accès simultané et SET TRANSACTION(7) pour plus d'informations.
Une transaction SQL en lecture seule ne peut pas modifier les tables permanentes. Ce paramètre contrôle le statut de lecture seule par défaut de chaque nouvelle transaction. La valeur par défaut est off (lecture/écriture).
Consulter SET TRANSACTION(7) pour plus d'informations.
Lors du fonctionnement avec le niveau d'isolation serializable, une transaction SQL en lecture seule et différable peut subir un certain délai avant d'être autorisée à continuer. Néanmoins, une fois qu'elle a commencé son exécution, elle n'encourt aucun des frais habituels nécessaires pour assurer sa sériabilité. Donc le code de sérialisation n'a aucune raison de forcer son annulation à cause de mises à jour concurrentes, ce qui rend cette option très intéressante pour les longues transactions en lecture seule.
Ce paramètre contrôle le statut différable par défaut de chaque nouvelle transaction. Il n'a actuellement aucun effet sur les transactions en lecture/écriture ou celles opérant à des niveaux d'isolation inférieurs à serializable. La valeur par défaut est off.
Consultez SET TRANSACTION(7) pour plus d'informations.
Contrôle l'exécution des triggers et règles relatifs à la réplication pour la session en cours. Seul un superutilisateur peut configurer cette variable. Sa modification résulte en l'annulation de tout plan de requête précédemment mis en cache. Les valeurs possibles sont origin (la valeur par défaut), replica et local. Voir ALTER TABLE(7) pour plus d'informations.
Interrompt toute instruction qui dure plus longtemps que ce nombre (indiqué en millisecondes). Le temps est décompté à partir du moment où la commande en provenance du client arrive sur le serveur. Si log_min_error_statement est configuré à ERROR, ou plus bas, l'instruction en cause est tracée. La valeur zéro (par défaut) désactive le décompte.
Il n'est pas recommandé de configurer statement_timeout dans postgresql.conf car cela affecte toutes les sessions.
VACUUM effectuera un parcours complet de la table si le champ pg_class.relfrozenxid de la table a atteint l'âge spécifié par ce paramètre. La valeur par défaut est 150 millions de transactions. Même si les utilisateurs peuvent positionner cette valeur à n'importe quelle valeur comprise entre zéro et 1 milliard, VACUUM limitera silencieusement la valeur effective à 95% de autovacuum_freeze_max_age, afin qu'un vacuum périodique manuel ait une chance de s'exécuter avant un autovacuum anti-bouclage ne soit lancé pour la table. Pour plus d'informations voyez Section 23.1.4, « Éviter les cycles des identifiants de transactions ».
Indique l'âge limite (en transactions) que VACUUM doit utiliser pour décider de remplacer les ID de transaction par FrozenXID lors du parcours d'une table. La valeur par défaut est 50 millions. Bien que les utilisateurs puissent configurer une valeur quelconque comprise entre zéro et 1 milliard, VACUUM limite silencieusement la valeur réelle à la moitié de la valeur de autovacuum_freeze_max_age afin que la valeur entre deux autovacuums forcés ne soit pas déraisonnablement courte. Pour plus d'informations, voir Section 23.1.4, « Éviter les cycles des identifiants de transactions ».
Configure le format de sortie pour les valeurs de type bytea. Les valeurs valides sont hex (la valeur par défaut) et escape (le format traditionnel de PostgreSQL). Voir Section 8.4, « Types de données binaires » pour plus d'informations. Le type bytea accepte toujours les deux formats en entrée, quelque soit la valeur de cette configuration.
Définit la manière de coder les valeurs binaires en XML. Ceci s'applique, par exemple, quand les valeurs bytea sont converties en XML par les fonctions xmlelement et xmlforest. Les valeurs possibles sont base64 et hex, qui sont toutes les deux définies dans le standard XML Schema. La valeur par défaut est base64. Pour plus d'informations sur les fonctions relatives à XML, voir Section 9.14, « Fonctions XML ».
Le choix effectif de cette valeur est une affaire de sensibilité, la seule restriction provenant des applications clientes. Les deux méthodes supportent toutes les valeurs possibles, et ce bien que le codage hexadécimal soit un peu plus grand que le codage en base64.
Définit si DOCUMENT ou CONTENT est implicite lors de la conversion entre XML et valeurs chaînes de caractères. Voir Section 8.13, « Type XML » pour la description. Les valeurs valides sont DOCUMENT et CONTENT. La valeur par défaut est CONTENT.
D'après le standard SQL, la commande pour configurer cette option est :
Nettoyage (vacuum)
automatique
SET XML OPTION { DOCUMENT | CONTENT };
Cette syntaxe est aussi disponible dans PostgreSQL.
Configure le format d'affichage des valeurs de type date et heure, ainsi que les règles d'interprétation des valeurs ambiguës de dates saisies. Pour des raisons historiques, cette variable contient deux composantes indépendantes : la spécification du format en sortie (ISO, Postgres, SQL ou German) et la spécification en entrée/sortie de l'ordre année/mois/jour (DMY, MDY ou YMD). Elles peuvent être configurées séparément ou ensemble. Les mots clés Euro et European sont des synonymes de DMY ; les mots clés US, NonEuro et NonEuropean sont des synonymes de MDY. Voir la Section 8.5, « Types date/heure » pour plus d'informations. La valeur par défaut est ISO, MDY, mais initdb initialise le fichier de configuration avec une valeur qui correspond au comportement de la locale lc_time choisie.
Positionne le format d'affichage pour les valeurs de type intervalle. La valeur sql_standard produira une sortie correspondant aux litéraux d'intervalles du standard SQL. La valeur postgres (qui est la valeur par défaut) produira une sortie correspondant à celle des versions de PostgreSQL™ antérieures à la 8.4 quand le paramètre datestyle était positionné à ISO. La valeur postgres_verbose produira une sortie correspondant à celle des versions de PostgreSQL™ antérieures à la 8.4 quand le paramètre DateStyle était positionné à une valeur autre que ISO La valeur iso_8601 produira une sortie correspondant au « format avec designateurs » d'intervalle de temps défini dans le paragraphe 4.4.3.2 de l'ISO 8601.
Le paramètre IntervalStyle affecte aussi l'interprétation des entrées ambigües d'intervalles. Voir Section 8.5.4, « Saisie d'intervalle » pour plus d'informations.
Configure le fuseau horaire pour l'affichage et l'interprétation de la date et de l'heure. Si ce paramètre n'est pas configuré explicitement, le serveur l'initialise avec le fuseau horaire indiqué par l'environnement système. Voir la Section 8.5.3, « Fuseaux horaires » pour plus d'informations.
Configure la liste des abréviations de fuseaux horaires acceptés par le serveur pour la saisie de données de type datetime. La valeur par défaut est 'Default', qui est une liste qui fonctionne presque dans le monde entier ; il y a aussi 'Australia' et 'India'. D'autres listes peuvent être définies pour une installation particulière. Voir Section B.3, « Fichiers de configuration date/heure » pour plus d'informations.
Ce paramètre ajuste le nombre de chiffres affichés par les valeurs à virgule flottante, ce qui inclut float4, float8 et les types de données géométriques. La valeur du paramètre est ajoutée au nombre standard de chiffres (FLT_DIG ou DBL_DIG). La valeur peut être initialisée à une valeur maximale de 3 pour inclure les chiffres partiellement significatifs ; c'est tout spécialement utile pour sauvegarder les données à virgule flottante qui ont besoin d'être restaurées exactement. Cette variable peut aussi être négative pour supprimer les chiffres non souhaités. Voir aussi Section 8.1.3, « Types à virgule flottante ».
Initialise l'encodage client (jeu de caractères). Par défaut, il s'agit de celui de la base de données. Les ensembles de caractères supportés par PostgreSQL™ sont décrits dans Section 22.3.1, « Jeux de caractères supportés ».
Initialise la langue d'affichage des messages. Les valeurs acceptables dépendent du système ; voir Section 22.1, « Support des locales » pour plus d'informations. Si cette variable est initialisée à une chaîne vide (valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.
Avec certains systèmes, cette catégorie de locale n'existe pas. Initialiser cette variable fonctionne toujours mais n'a aucun effet. De même, il est possible qu'il n'existe pas de traduction des messages dans la langue sélectionnée. Dans ce cas, les messages sont affichés en anglais.
Seuls les superutilisateurs peuvent modifier ce paramètre car il affecte aussi bien les messages envoyés dans les traces du serveur que ceux envoyés au client.
Initialise la locale à utiliser pour le formatage des montants monétaires (pour la famille de fonctions to_char, par exemple). Les valeurs acceptables dépendent du système ; voir la Section 22.1, « Support des locales » pour plus d'informations. Si cette variable est initialisée à une chaîne vide (valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur, et une valeur incorrecte pourrait dégrader la lisibilité des traces du serveur.
Initialise la locale à utiliser pour le formatage des nombres (pour la famille de fonctions to_char, par exemple). Les valeurs acceptables dépendent du système ; voir la Section 22.1, « Support des locales » pour plus d'informations. Si cette variable est initialisée à une chaîne vide (valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.
Initialise la locale à utiliser pour le formatage des valeurs de date et d'heure, par exemple avec la famille de fonctions to_char. Les valeurs acceptables dépendent du système ; voir la Section 22.1, « Support des locales » pour plus d'informations. Si cette variable est initialisée à une chaîne vide (valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.
Sélectionne la configuration de recherche plein texte utilisée par les variantes des fonctions de recherche plein texte qui n'ont pas d'argument explicite pour préciser la configuration. Voir Chapitre 12, Recherche plein texte pour plus d'informations. La valeur par défaut est pg_catalog.simple mais initdb initialise le fichier de configuration avec une valeur qui correspond à la locale choisie pour lc_ctype s'il est possible d'identifier une configuration correspondant à la locale.
Chemin de recherche utilisé lorsqu'un module chargeable dynamiquement doit être ouvert et que le nom de fichier indiqué dans la commande CREATE FUNCTION ou LOAD ne contient pas d'indication de répertoire (c'est-à-dire que le nom ne contient pas de slash).
La valeur de dynamic_library_path doit être une liste de chemins absolus séparés par des virgules (ou des points virgules sous Windows). Si un élément de la liste débute par la chaîne spéciale $libdir, le répertoire des bibliothèques internes du paquetage PostgreSQL™ est substitué à $libdir. C'est l'emplacement où sont installés les modules fournis par la distribution PostgreSQL™ standard. (La commande pg_config --pkglibdir permet de connaître le nom de ce répertoire.) Par exemple :
dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
ou dans un environnement Windows :
dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
La valeur par défaut de ce paramètre est '$libdir'. Si la valeur est une chaîne vide, la recherche automatique du chemin est désactivée.
Ce paramètre peut être modifié à l'exécution par les superutilisateurs, mais un tel paramétrage ne persiste que pour la durée de la connexion du client. Il est donc préférable de ne réserver cette méthode qu'à des fins de développement. Il est recommandé d'initialiser ce paramètre dans le fichier de configuration postgresql.conf.
Limite souple haute de la taille de l'ensemble renvoyé par un index GIN. Pour plus d'informations, voir Section 54.4, « Conseils et astuces GIN ».
Indique les bibliothèques partagées à charger à l'initialisation d'une connexion. Si plusieurs bibliothèques doivent être chargées, leurs noms sont séparés par des virgules. Tous les noms de bibliothèques sont convertis en minuscule sauf s'ils sont compris entre des guillemets doubles. Ce paramètre ne peut pas être modifié après le démarrage de la session.
Comme il ne s'agit pas d'une option réservée aux superutilisateurs, les bibliothèques pouvant être chargées sont restreintes à celles du sous-répertoire plugins du répertoire standard des bibliothèques. (Il est de la responsabilité de l'administrateur de bases de données de s'assurer que seules des bibliothèques « saines » s'y trouvent.) Les entrées dans local_preload_libraries peuvent indiquer ce répertoire explicitement, par exemple $libdir/plugins/ma_lib, ou n'indiquer que le nom de la bibliothèque -- ma_lib a le même effet que $libdir/plugins/ma_lib.
Contrairement à shared_preload_libraries, il n'y a pas de gain de performance à charger une bibliothèque au démarrage d'une session ou à sa première utilisation. Le but de cette fonctionnalité est d'autoriser le chargement de bibliothèques de débogage ou de mesure de performance dans certaines sessions spécifiques sans commande LOAD explicite. Par exemple, le débogage peut être activé pour une session en configurant ce paramètre avec la variable d'environnement PGOPTIONS.
Si une bibliothèque indiquée n'est pas trouvée, la tentative de connexion échoue.
Toute bibliothèque supportée par PostgreSQL contient un « bloc magique » qui permet d'en garantir la compatibilité. Pour cette raison, les bibliothèques non PostgreSQL ne peuvent pas être chargées de cette façon.