client_min_messages
(enum
)
Contrôle les niveaux de
message envoyés au client. Les valeurs valides sont
DEBUG5
, DEBUG4
,
DEBUG3
, DEBUG2
,
DEBUG1
, LOG
,
NOTICE
, WARNING
et
ERROR
. Chaque niveau inclut tous les
niveaux qui le suivent. Plus on progresse dans la liste,
plus le nombre de messages envoyés est faible. NOTICE
est la valeur par défaut. LOG
a ici une portée
différente de celle de log_min_messages
.
Les messages de niveau INFO
sont toujours envoyés au
client.
search_path
(string
)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. Tout nom qui ne correspond pas à un
schéma existant ou qui correspond à un schéma pour lequel l'utilisateur
n'a pas le droit USAGE
, est ignoré silencieusement.
Si un des éléments de la liste est le nom spécial $user
,
alors le schéma dont le nom correspond à la valeur retournée par
CURRENT_USER
est substitué, s'il existe et que
l'utilisateur ait le droit USAGE
sur ce schéma
(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_
, s'il existe,
est toujours parcouru. Il peut être explicitement ajouté au chemin
à l'aide de l'alias nnn
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 valide 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
. 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.25). 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.
row_security
(boolean
)
Cette variable indique s'il convient de lever une erreur
au lieu d'appliquer la politique de sécurité au niveau
ligne. Lorsque positionnée à on
, les
politiques s'appliquent normalement. Lorsque positionnée
à off
, les requêtes qui remplissent les
conditions d'au moins une politique de sécurité échouent. La
valeur par défaut est on
. Positionnez la
valeur sur off
dans le cas où une visibilité
limitée des lignes pourrait causer des résultats incorrects ; par
exemple, pg_dump effectue ce changement
par défaut. Cette variable n'a aucun effet sur les rôles qui
outrepassent toutes les politiques de sécurité niveau ligne, à
savoir, les superutilisateurs et les rôles qui possèdent l'attribut
BYPASSRLS
.
Pour plus d'informations sur les politiques de sécurité niveau ligne, voir CREATE POLICY.
default_tablespace
(string
)
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 22.6.
temp_tablespaces
(string
)
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.
check_function_bodies
(boolean
)
Ce paramètre est habituellement positionné à on
.
Positionné à off
, il désactive la validation du
corps de la fonction lors de CREATE FUNCTION.
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.
default_transaction_isolation
(enum
)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 et SET TRANSACTION pour plus d'informations.
default_transaction_read_only
(boolean
)
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 pour plus d'informations.
default_transaction_deferrable
(boolean
)
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 pour plus d'informations.
transaction_isolation
(enum
)
Ce paramètre reflète le niveau d'isolation de la transaction. Au début de chaque transaction, il est configuré à la valeur courante du paramètre default_transaction_isolation. Toute tentative ultérieure de modification est équivalente à une commande SET TRANSACTION.
transaction_read_only
(boolean
)
Ce paramètre reflète le statut lecture-seule de la transaction courante. Au début de chaque transaction, il est configuré à la valeur courante du paramètre default_transaction_read_only. Toute tentative de modification ultérieure est équivalente à une commande SET TRANSACTION.
transaction_deferrable
(boolean
)
Ce paramètre reflète le statut de reportabilité de la transaction courante. Au début de chaque transaction, il est configuré à la valeur courante du paramètre default_transaction_deferrable. Toute tentative de modification ultérieure est équivalente à une commande SET TRANSACTION.
session_replication_role
(enum
)
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
pour plus d'informations.
statement_timeout
(integer
)
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.
lock_timeout
(integer
)
Annule toute requête qui attend plus longtemps que le nombre de
millisecondes indiqué sur ce paramètre lors de la tentative
d'acquisition d'un verrou sur une table, un index, une ligne ou tout
autre objet d'une base de données. La limite de temps s'applique
séparément pour chaque tentative d'acquisition d'un verrou. La limite
s'applique pour les demandes de verrous explicites (comme LOCK
TABLE
, ou SELECT FOR UPDATE
sans
NOWAIT
) et pour ceux acquis implicitement.
Une valeur de zéro (valeur par défaut) désactive ce
comportement.
Contrairement à statement_timeout
, ce délai peut
seulement intervenir lors de l'attente de verrous. Notez que si
statement_timeout
est différent de zéro, il est
plutôt inutile de configurer lock_timeout
à la
même valeur ou à une valeur plus importante puisque le délai sur la
requête se déclenchera toujours avant. Si
log_min_error_statement
est configuré à
ERROR
ou plus bas, l'instruction qui dépasse ce délai
sera tracé.
Configurer lock_timeout
dans
postgresql.conf
n'est pas recommandé car cela
affecterait toutes les sessions.
idle_in_transaction_session_timeout
(integer
)
Termine toute session ayant une transaction ouverte ne faisant rien depuis plus longtemps que la durée indiquée en milliseconde par ce paramètre. Cela permet de relâcher les verrous posés par cette transaction et de réutiliser le slot de connexion ainsi libérée. Cela permet aussi aux lignes visibles par cette seule transaction d'être nettoyées. Voir Section 24.1 pour plus de détails sur ce point.
La valeur par défaut de 0 désactive cette fonctionnalité.
vacuum_freeze_table_age
(integer
)
VACUUM
effectuera un parcours agressif de la table si
le champ pg_class
.relfrozenxid
de la table a atteint l'âge spécifié par ce paramètre. Un parcours agressif diffère
d'un VACUUM
standard dans le sens où il visite chaque bloc qui
pourrait contenir des XID ou MXID non gelés, pas seulement ceux qui pourraient
contenir des lignes mortes. 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
2 milliards, 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 24.1.5.
vacuum_freeze_min_age
(integer
)
Indique l'âge limite (en transactions) que VACUUM
doit utiliser pour décider de geler les versions de ligne 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 24.1.5.
vacuum_multixact_freeze_table_age
(integer
)
VACUUM
réalise un parcours agressif de la table si le
champ pg_class
.relminmxid
de la table a atteint l'âge indiqué par ce paramètre. Un parcours agressif diffère
d'un VACUUM
standard dans le sens où il visite chaque bloc qui
pourrait contenir des XID ou MXID non gelés, pas seulement ceux qui pourraient
contenir des lignes mortes. La valeur par
défaut est de 150 millions de multixacts. Bien que les utilisateurs
peuvent configurer cette valeur entre zéro et deux milliards,
VACUUM
limitera silencieusement la valeur réelle à
95% de autovacuum_multixact_freeze_max_age, pour
qu'un VACUUM
manuel périodique ait une chance d'être
exécuté avant qu'une opération anti-réutilisation d'identifiants ne soit
exécutée sur la table. Pour plus d'informations, voir Section 24.1.5.1.
vacuum_multixact_freeze_min_age
(integer
)
Précise l'âge limite (en multixacts) que VACUUM
doit
utiliser pour décider s'il doit remplacer les identifiants multixact
avec un nouvel identifiant de transaction ou de multixact lors de son
parcours de la table. La valeur par défaut est de 5 millions de
multixacts. Bien que les utilisateurs peuvent configurer cette valeur
entre zéro et un milliard, VACUUM
limitera
silencieusement la valeur réelle à la moitié de la valeur de
autovacuum_multixact_freeze_max_age, pour qu'il y
ait un délai raisonnable entre deux autovacuums forcés. Pour plus
d'informations, voir Section 24.1.5.1.
bytea_output
(enum
)
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
pour plus d'informations. Le type bytea
accepte toujours
les deux formats en entrée, quelque soit la valeur de cette
configuration.
xmlbinary
(enum
)
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.
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.
xmloption
(enum
)
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 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 :
SET XML OPTION { DOCUMENT | CONTENT };
Cette syntaxe est aussi disponible dans PostgreSQL.
Plusieurs paramètres sont disponibles pour le préchargement de
bibliothèques partagées sur le serveur. Ces bibliothèques peuvent servir
à ajouter des fonctionnalités supplémentaires ou à améliorer les
performances. Par exemple, une configuration à
'$libdir/mabibliotheque'
force le chargement de la
bibliothèque mabibliotheque.so
(ou sur certaines
plateformes de mabibliotheque.sl
) à partir du répertoire
standard d'installation. Les différences entre les paramètres concernent
la prise d'effet et les droits requis pour les modifier.
Les bibliothèques de procédures stockées pour PostgreSQL
peuvent être préchargées de cette façon, habituellement en utilisant la syntaxe
'$libdir/plXXX'
où XXX
est
pgsql
, perl
,
tcl
ou python
.
Seules les bibliothèques partagées spécifiquement codées pour PostgreSQL
peuvent être chargées de cette façon. Chaque bibliothèque supportée par
PostgreSQL a un « bloc magique » qui est vérifié pour garantir
sa comptabilité. De ce fait, les bibliothèques non compatibles avec
PostgreSQL ne peuvent pas être gérées ainsi. Vous devriez pouvoir utiliser
les capacités du système pour cela, tel que la variable d'environnement
LD_PRELOAD
.
En général, il est préférable de se référer à la documentation d'un module spécifique pour trouver le bon moyen permettant de charger le module.
local_preload_libraries
(string
)
Cette variable indique une ou plusieurs bibliothèques partagées chargées au début de la connexion. Elle contient une liste de noms de bibliothèques, séparés par des virgules, où chaque nom est interprété comme par la commande LOAD. Les espaces blancs entre les entrées sont ignorés. Placer le nom d'une bibliothèque entre guillemets doubles si vous avez besoin d'inclure des espaces blancs ou des virgules dans le nom. La valeur de ce paramètre n'est pris en compte qu'au début de la connexion. Les modifications ultérieures n'ont pas d'effet sur les connexions déjà établies. Si une bibliothèque indiquée est introuvable, la tentative de connexion échouera. Seuls les superutilisateurs peuvent modifier cette configuration.
Cette option est configurable par tout utilisateur. De ce fait, les
bibliothèques pouvant être chargées sont restreintes à celles
disponibles dans le sous-répertoire plugins
du
répertoire des bibliothèques de l'installation. C'est de la responsabilité
de l'administrateur de s'assurer que seules des bibliothèques
« sûres » y soient installées.) Les éléments de
local_preload_libraries
peuvent indiquer ce répertoire
explicitement, par exemple
$libdir/plugins/mabibliotheque
, ou indiquer seulement
le nom de la bibliothèque -- mabibliotheque
, ce
qui aurait le même effet que $libdir/plugins/mabibliotheque
.
Le but de cette fonctionnalité est de permettre aux utilisateurs
non privilégiés de charger des bibliothèques de débuggage ou de
mesures de performances dans des sessions explicites sans avoir à
exécuter manuellement une commande LOAD
. À cette
fin, une configuration classique de ce paramètre serait d'utiliser
la variable d'environnement PGOPTIONS
sur le client
ou d'utiliser la commande ALTER ROLE SET
.
Néanmoins, sauf si un module est conçu spécifiquement pour être utilisé de cette façon par des utilisateurs non administrateurs, ceci n'est pas le bon paramétrage pour vous. Regardez plutôt session_preload_libraries.
session_preload_libraries
(string
)
Cette variable indique une ou plusieurs bibliothèques partagées chargées au début de la connexion. Elle contient une liste de noms de bibliothèques, séparés par des virgules, où chaque nom est interprété comme par la commande LOAD. Les espaces blancs entre les entrées sont ignorés. Placer le nom d'une bibliothèque entre guillemets doubles si vous avez besoin d'inclure des espaces blancs ou des virgules dans le nom. La valeur de ce paramètre n'est pris en compte qu'au début de la connexion. Les modifications ultérieures n'ont pas d'effet sur les connexions déjà établies. Si une bibliothèque indiquée est introuvable, la tentative de connexion échouera. Seuls les superutilisateurs peuvent modifier cette configuration.
Le but de cette fonctionnalité est de permettre le chargement de
bibliothèques de débuggage ou de mesure de performances dans des
sessions explicites sans avoir à exécuter manuellement une commande
LOAD
. Par exemple, auto_explain
pourrait être activé pour toutes les sessions si un certain utilisateur
se connecte, en configurant son compte avec la commande ALTER
ROLE SET
. De plus, ce paramètre peut être modifié sans avoir
à redémarrer le serveur (les changements ne prennent effet que pour les
connexions suivantes), donc il est plus facile d'ajouter de nouveaux
modules de cette façon, même s'ils s'appliquent à toutes les sessions.
Contrairement à shared_preload_libraries, il n'y a pas vraiment un gros avantage en terme de performances à charger une bibliothèque en début de session plutôt qu'à sa première utilisation. Néanmoins, ceci n'est plus vrai si un système de pooling de connexions est mis en place.
shared_preload_libraries
(string
)
Cette variable indique une ou plusieurs bibliothèques partagées chargées au démarrage du serveur. Elle contient une liste de noms de bibliothèques, séparés par des virgules, où chaque nom est interprété comme par la commande LOAD. Les espaces blancs entre les entrées sont ignorés. Placer le nom d'une bibliothèque entre guillemets doubles si vous avez besoin d'inclure des espaces blancs ou des virgules dans le nom. La valeur de ce paramètre n'est pris en compte qu'au démarrage du serveur. Si une bibliothèque indiquée est introuvable, la tentative de démarrage échouera. Seuls les superutilisateurs peuvent modifier cette configuration.
Certaines bibliothèques ont besoin de réaliser certaines opérations qui ne peuvent se faire qu'au démarrage du processus postmaster, comme allouer de la mémoire partagée, réserver des verrous à faible poids, ou démarrer des background workers. Ces bibliothèques doivent être chargées au démarrage du serveur via ce paramètre. Voir la documentation de chaque bibliothèque pour les détails.
Les autres bibliothèques peuvent aussi être préchargées. En préchargeant une bibliothèque partagée, le temps de démarrage de la bibliothèque est évité lorsque la bibliothèque est utilisée pour la première fois. Néanmoins, le temps de démarrer chaque nouveau processus serveur pourrait augmenter légèrement, même si le processus n'utilise jamais cette bibliothèque. Donc ce paramètre est seulement recommandé pour les bibliothèques qui seront utilisées par la majorité des sessions. De plus, changer ce paramètre requiert un redémarrage du serveur, donc ce n'est pas le bon paramètre pour les taches de débuggage par exemple. Utilisez session_preload_libraries pour cela.
Sur les hôtes Windows, précharger une bibliothèque au démarrage du serveur
ne réduira pas le temps nécessaire pour démarrer un nouveau processus
serveur. Chaque processus serveur rechargera toutes les bibliothèques
préchargées. Néanmoins, shared_preload_libraries
est toujous utile sur les hôtes Windows pour les bibliothèques qui ont
besoin de réaliser des opérations au démarrage du postmaster.
gin_pending_list_limit
(integer
)
Positionne la taille maximale de la liste d'attente GIN qui est
utilisée lorsque fastupdate
est activé. Si
la liste dépasse cette taille maximale, elle est allégée en
déplaçant des entrées en masse vers la structure de données
principale GIN. La valeur par défaut est quatre mégaoctets
(4MB
). Ce paramètre peut être surchargé pour
chaque index GIN en modifiant les paramètres de stockage de l'index.
Voir Section 64.4.1 et Section 64.5
pour plus d'informations.
datestyle
(string
)
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 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.
IntervalStyle
(enum
)
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
pour plus d'informations.
TimeZone
(string
)
Configure le fuseau horaire pour l'affichage et l'interprétation
de la date et de l'heure.
La valeur par défaut est GMT
, mais elle est généralement surchargée
dans le fichier postgresql.conf
; initdb
installera une configuration correspondant à l'environnement système.
Voir Section 8.5.3 pour plus d'informations.
timezone_abbreviations
(string
)
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.4 pour plus d'informations.
extra_float_digits
(integer
)
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.
client_encoding
(string
)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 23.3.1.
lc_messages
(string
)Initialise la langue d'affichage des messages. Les valeurs acceptables dépendent du système ; voir Section 23.1 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.
lc_monetary
(string
)
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 23.1 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.
lc_numeric
(string
)
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 23.1
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.
lc_time
(string
)
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 23.1 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.
default_text_search_config
(string
)
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 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.
dynamic_library_path
(string
)
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'
Pour plus d'informations sur la gestion des schémas, voir Section 5.8. En particulier, la configuration par défaut est seulement convenable quand la base de données a un seul utilisateur ou quelques utilisateurs qui se font confiance mutuellement.
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
.
gin_fuzzy_search_limit
(integer
)Limite souple haute de la taille de l'ensemble renvoyé par un index GIN. Pour plus d'informations, voir Section 64.5.