16.4. Configuration à l'exécution

Spécifie les adresses TCP/IP sur lesquelles le serveur écoute les connexions des applications client. La valeur prend la forme d'une liste de noms d'hôte ou d'adresses IP numériques séparés par des virgules. L'entrée spéciale * correspond à toutes les interfaces IP disponibles. Si la liste est vide, le serveur n'écoute aucune interface IP, auquel cas seuls les sockets de domaine Unix peuvent être utilisés pour s'y connecter. La valeur par défaut est localhost, ce qui autorise seulement les connexions locales de type << loopback >>. Ce paramètre peut seulement être configuré au lancement du serveur.

Le port TCP sur lequel le serveur écoute ; 5432 par défaut. Notez que le même numéro de port est utilisé pour toutes les adresses IP où le serveur écoute. Ce paramètre peut seulement être configuré au lancement du serveur.

Détermine le nombre maximum de connexions concurrentes au serveur de la base de données. La valeur par défaut typique est 100 mais pourrait être bien moindre si vos paramétrages du noyau ne le supportent pas (ce qui est déterminé lors du initdb). Ce paramètre peut seulement être initialisé au lancement du serveur.

Augmenter ce paramètre pourrait faire que PostgreSQL réclame plus de mémoire partagée System V ou de sémaphores que ne le permet la configuration par défaut de votre système d'exploitation. Voir la Section 16.5.1 pour plus d'informations sur la façon d'ajuster ces paramètres si nécessaire.

Détermine le nombre de connexions (<< slots >>) réservés aux connexions des superutilisateurs PostgreSQL. Au plus max_connections connexions peuvent être actives simultanément. À chaque fois que le nombre de connexions actives en même temps est d'au moins max_connections moins superuser_reserved_connections, les nouvelles connexions ne seront acceptées que pour les superutilisateurs.

La valeur par défaut est de 2. La valeur doit être plus petite que la valeur de max_connections. Ce paramètre peut seulement être configuré uniquement au lancement du serveur.

Spécifie le répertoire du socket de domaine Unix sur lequel le serveur écoute les connexions des applications clients. Par défaut, il s'agit de /tmp mais cela peut être modifié au moment de la construction. Ce paramètre peut seulement être configuré au lancement du serveur.

Configure le groupe propriétaire du socket de domaine Unix (l'utilisateur propriétaire de la socket est toujours l'utilisateur qui lance le serveur). En combinaison avec l'option unix_socket_permissions, ceci peut être utilisé comme un mécanisme de contrôle d'accès supplémentaire pour les connexions de domaine Unix. Par défaut, il s'agit d'une chaîne vide utilisant le groupe par défaut pour l'utilisateur en cours. Cette option est seulement disponible au lancement du serveur.

Configure les droits d'accès au socket de domaine Unix. Ce socket utilise l'ensemble habituel des droits du système de fichiers Unix. La spécification de l'option est attendue dans le mode numérique avec la forme acceptée par les appels système chmod et umask (pour utiliser le format octal, ce nombre doit commencer avec un 0 (zéro)).

Les droits par défaut sont 0777, signifiant que tout le monde peut se connecter. Les alternatives raisonnables sont 0770 (seul l'utilisateur et le groupe, voir aussi unix_socket_group) et 0700 (seul l'utilisateur) (notez, que pour un socket de domaine Unix, seul le droit d'accès en écriture importe et, donc, il n'est pas nécessaire de donner ou de révoquer les droits de lecture ou d'exécution).

Ce mécanisme de contrôle d'accès est indépendant de celui décrit dans le Chapitre 19.

Cette option est seulement disponible au lancement du serveur.

Spécifie le nom broadcast de Rendezvous. Par défaut, le nom de l'ordinateur est utilisé, spécifié comme une chaîne vide. Cette option est ignorée si le serveur n'était pas compilé avec le support Rendezvous. Cette option est seulement configurable au lancement du serveur.

Temps maximum pour terminer l'authentification du client en secondes. Si un client n'a pas terminé le protocole d'authentification dans ce délai, le serveur rompt la connexion. Ceci protège le serveur des clients bloqués occupant une connexion indéfiniment. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf. La valeur par défaut est de 60 secondes.

Active les connexions SSL. Merci de lire Section 16.8 avant d'utiliser ceci. C'est désactivé par défaut. Ce paramètre est seulement disponible au lancement du serveur.

Indique la quantité de données pouvant transiter sur une connexion en SSL avant qu'une renégotiation de la session ne survienne. La renégotiation de la session diminue le risque d'analyse du chiffrement lorsque de gros volumes de données sont envoyées mais cela a un coût important pour les performances. Les données émises et réceptionnées sont prises en compte lors de la vérification de la limite. Si ce paramètre est à 0, la renégotiation est désactivée. La valeur par défaut est de 512 Mo.

Cette option détermine si le mot de passe doit être crypté quand un mot de passe est spécifié dans CREATE USER ou ALTER USER sans écrire soit ENCRYPTED soit UNENCRYPTED. Actif par défaut (crypte le mot de passe).

Configure l'emplacement du fichier contenant la clé secrète du serveur Kerberos. Voir Section 19.2.3 pour des détails.

Ceci autorise les noms d'utilisateur par base de données. Désactivé par défaut.

Si cette option est activée, vous devrez créer des utilisateurs de nom nomutilisateur@nom_base. Quand nomutilisateur est passé pour un client en cours de connexion, @ et le nom de la base de données est ajouté au nom de l'utilisateur et ce nom d'utilisateur spécifique à la base de données est recherché dans le serveur. Notez que lorsque vous créez des utilisateurs dont le nom contient un @ dans l'environnement SQL, vous devez mettre le nom entre guillemets.

Cette option activée, vous pouvez toujours créer des utilisateurs globaux ordinaires. Ajoutez simplement @ lors de la spécification du nom du client. Le @ sera supprimé avant de chercher le nom de l'utilisateur dans le serveur.

Initialise le nombre de tampons en mémoire partagée utilisés par le serveur de bases de données. La valeur par défaut est de 1000 mais pourrait être moindre si la configuration de votre noyau ne le supporte pas (c'est déterminé lors de l'exécution d'initdb). Chaque tampon fait 8192 octets sauf si une valeur différente de BLCKSZ a été choisie lors de la construction du serveur. Ce paramétrage doit valoir au moins 16, mais aussi au moins deux fois la valeur de max_connections ; néanmoins, des valeurs significativement plus importantes que ce minimum sont généralement nécessaires pour de bonnes performances. Des valeurs de quelques milliers sont recommandées pour des installations de production. Cette option n'est initialisable qu'au lancement du serveur.

Augmenter ce paramètre pourrait faire en sorte que PostgreSQL réclame plus de mémoire partagé System V que ce que la configuration par défaut de votre système d'exploitation ne peut gérer. Voir la Section 16.5.1 pour plus d'informations sur l'ajustement de ces paramètres si nécessaire.

Spécifie la mémoire à utiliser pour les opérations de tri interne et pour les tables de découpage avant de basculer sur des fichiers temporaires sur disque. La valeur est spécifiée en Ko et vaut par défaut 1024 (soit 1 Mo). Notez que pour une requête complexe, plusieurs tris ou opérations de hachage pourraient être exécutés en parallèle ; chacun d'entre eux se verra autorisé à utiliser autant de mémoire que cette valeur indique avant de commencer à placer des données dans des fichiers temporaires. De plus, plusieurs sessions en cours d'exécution pourraient exécuter des opérations simultanément. Donc, la mémoire totale utilisée pourrait être plusieurs fois la valeur de work_mem ; il est nécessaire de conserver ce fait en tête lors du choix de cette valeur. Les opérations de tri sont utilisées pour ORDER BY, DISTINCT et les jointures d'assemblage. Les tables de découpage sont utilisées dans les jointures de découpage, les agrégations basées sur le découpage et le traitement des sous-requêtes IN.

Spécifie la mémoire maximum utilisée dans les opérations de maintenance telles que VACUUM, CREATE INDEX et ALTER TABLE ADD FOREIGN KEY. La valeur est spécifiée en Ko et vaut par défaut 16384 (soit 16 Mo). Comme une seule de ces opérations peut être exécutée à un moment donné sur une session de la base de données et qu'une installation n'en exécute pas beaucoup en même temps, il est possible d'initialiser cette variable à une valeur bien plus importante que work_mem. De gros paramétrages pourraient améliorer les performances sur les opérations VACUUM et pour la restauration des sauvegardes de bases de données.

Spécifie la profondeur maximum de la pile d'exécution du serveur. La configuration idéale pour ce paramètre est la limite actuelle de la pile forcée par le noyau (configurée par ulimit -s ou une commande locale équivalente), moins une marge de sécurité d'un Mo ou plus. La marge de sécurité est nécessaire parce que la profondeur de la pile n'est pas vérifiée dans chaque routine du serveur mais seulement dans les routines clés potentiellement récursives telles que l'évaluation d'une expression. Configurer ce paramètre à une valeur plus importante que la limite réelle du noyau signifiera qu'une fonction récursive peut arrêter brutalement un processus serveur individuel. Le paramétrage par défaut est de 2048 Ko (soit 2 Mo), ce qui est très petit et comporte peu de risques. Néanmoins, cela pourrait être trop petit pour autoriser l'exécution de fonctions complexes.

Initialise le nombre maximum de pages disque pour lesquelles les espaces libres sont tracés dans la carte partagée des espaces libres. Six octets de mémoire partagée sont consommés pour chaque emplacement de page. Ce paramétrage doit être supérieur à 16 * max_fsm_relations. Par défaut, il est à 20000. Cette option n'est configurable qu'au lancement du serveur.

Initialise le nombre maximum de relations (tables et index) pour lesquelles les espaces libres sont tracés dans la carte partagée de l'espace libre. En gros, 50 octets de mémoire partagée sont consommés par emplacement. La valeur par défaut est de 1000. Cette option n'est configurable qu'au lancement du serveur.

Initialise le nombre maximum de fichiers ouverts simultanément permis pour chaque sous-processus serveur. La valeur par défaut est de 1000. Si le noyau force une limite par processus, vous n'avez pas besoin de vous inquiéter de ce paramétrage. Mais, sur certaines plateformes (notamment la plupart des systèmes BSD), le noyau autorisera des processus individuels à ouvrir beaucoup plus de fichiers que le système ne peut réellement supporter quand un grand nombre de processus essaient d'ouvrir autant de fichiers. Si vous récupérez des erreurs du type << Too many open files >> (trop de fichiers ouverts), essayez de réduire ce paramètre. Cette option peut aussi être configurée au lancement du serveur.

Cette variable spécifie une ou plusieurs bibliothèques préchargées au lancement du serveur. Une fonction d'initialisation sans paramètre peut être appelée pour chaque bibliothèque. Pour cela, ajouter un caractère deux points et le nom de la fonction d'initialisation après le nom de la bibliothèque. Par exemple, '$libdir/malib:malib_init' causerait le préchargement de malib et l'exécution de malib_init. Si plus d'une bibliothèque doit être chargée, séparez leur nom par des virgules.

Si une bibliothèque spécifique ou une fonction d'initialisation sont introuvables, le serveur échouera au lancement.

Les bibliothèques des langages de procédure de PostgreSQL peuvent être préchargées de cette façon, typiquement en utilisant la syntaxe '$libdir/plXXX:plXXX_init' où XXX est soit pgsql soit perl soit tcl soit python.

En préchargeant une bibliothèque partagée (et en l'initialisant dans les cas applicables), le temps de lancement de la bibliothèque est évité à la première utilisation de la bibliothèque. Néanmoins, le temps de lancer chaque nouveau processus pourrait augmenter légèrement même si le processus n'utilise pas la bibliothèque. Donc, cette option est seulement recommandée pour les bibliothèques qui seront utilisées par la majorité des sessions.

Le temps, en millisecondes, de repos du processus quand la limite de coût a été atteinte. La valeur par défaut vaut 0, ce qui désactive la fonctionnalité du délai du VACUUM basé sur le coût. Une valeur positive active cette fonctionnalité. Notez que, sur plusieurs systèmes, la résolution réelle des délais de repos est de 10 millisecondes ; configurer vacuum_cost_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat que de le configurer au prochain multiple de 10.

Le coût estimé pour nettoyer via VACUUM un tampon trouvé dans le cache des tampons partagés. Cela représente le coût pour verrouiller le lot de tampons, la recherche dans la table de découpage partagée et le parcours du contenu de la page. La valeur par défaut vaut 1.

Le coût estimé pour nettoyer via VACUUM un tampon qui doit être lu sur le disque. Ceci représente l'effort pour verrouiller le lot de tampons, la recherche dans la table de découpage partagée, la lecture du bloc désiré du disque et le parcours de son contenu. La valeur par défaut vaut 10.

Le coût estimé chargé quand VACUUM modifie un bloc qui était précédemment propre. Cela représente les entrées/sorties supplémentaires requis pour vider le bloc sale de nouveau sur le disque. La valeur par défaut vaut 20.

Le coût accumulé qui causera l'endormissement du processus de VACUUM. La valeur par défaut vaut 200.

Spécifie le délai entre les tours d'activité du processus d'écriture en tâche de fond. À chaque tour, le processus écrit un certain nombre de tampons sales (contrôlable par les paramètres suivants). Les tampons sélectionnées seront toujours ceux les moins récemment utilisés parmi les tampons sales en cours. Puis, il s'endort pour bgwriter_delay millisecondes et recommande. La valeur par défaut est de 200. Notez que sur de nombreux systèmes, la résolution réelle des délais de sommeil est de 10 millisecondes; configurer bgwriter_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat que de le configurer au multiple de 10 supérieur. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

À chaque tour, pas plus que ce pourcentage de tampons sales ne seront écrits (ne terminant tout fraction sur le prochain nombre de tampons). La valeur par défaut est 1. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

À chaque tour, pas plus que ce nombre de tampons partagés sera écrit. La valeur par défaut vaut 100. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

Si cette option est activée, le serveur PostgreSQL utilisera l'appel système fsync() à plusieurs endroits pour s'assurer que les mises à jour sont écrites physiquement sur le disque. Ceci vous assure que le groupe de bases de données retournera à un état cohérent après un arrêt brutal du système d'exploitation ou suite à un problème matériel.

Néanmoins, utiliser fsync() implique des coûts au niveau performance : lorsqu'une transaction est validée, PostgreSQL doit attendre que le système d'exploitation vide les WAL sur disque. Lorsque fsync est désactivé, le système d'exploitation est autorisé à faire de son mieux en utilisant des tampons pour les écritures, en ordonnant et en ajoutant des délais aux écritures. Néanmoins, si le système s'arrête brutalement, les résultats des dernières transactions validées pourraient être perdus en partie ou complètement. Dans le pire des cas, une corruption non récupérable des données pourrait survenir (les arrêts brutaux du serveur de bases de données lui-même ne sont pas un facteur de risque ici. Seul l'arrêt brutal au niveau du système d'exploitation crée un risque de corruption).

À cause des risques encourus, il n'existe pas de paramétrage universel pour fsync. Certains administrateurs désactivent en permanence fsync alors que d'autres ne le désactivent que pour les charges importantes s'il existe un moyen de recommencer proprement si quelque chose se passe mal. Mais d'autres administrateurs laissent toujours fsync activé. La valeur par défaut est d'activer fsync pour une confiance maximale. Si vous avez confiance en votre système d'exploitation (ou sur la sauvegarde sur batterie), vous pouvez considérer la désactivation de fsync.

Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf file.

Méthode utilisée pour forcer les mises à jour des WAL sur le disque. Les valeurs possibles sont fsync (appel de fsync() à chaque validation), fdatasync (appel de fdatasync() à chaque validation), fsync_writethrough (appel de _commit() à chaque validation sur Windows), open_sync (écriture des fichiers WAL avec l'option O_SYNC de open()) et open_datasync (écriture des fichiers WAL avec l'option O_DSYNC de open()). Toutes ces options ne sont pas disponibles sur toutes les plateformes. Si fsync est désactivée, alors cette configuration n'a pas d'intérêt. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf.

Nombre de tampons de pages disque alloués en mémoire partagée pour les données WAL. La valeur par défaut vaut 8. Ce paramétrage a seulement besoin d'être assez important pour contenir toutes les données WAL générées par une transaction typique. Cette option est seulement disponible au lancement du serveur.

Délai entre l'enregistrement d'une validation dans le tampon WAL et le vidage du tampon sur le disque, en microsecondes. Un délai différent de zéro peut autoriser la validation de plusieurs transactions sur un seul appel système fsync() si la charge système est assez importante pour que des transactions supplémentaires soient prêtes dans l'intervalle donné. Mais le délai est perdu si aucune autre transaction n'est prête à être validée. Du coup, le délai n'est traité que si au moins commit_siblings autres transactions sont actives au moment où le processus serveur a écrit son enregistrement de validation. La valeur par défaut est zéro, donc pas de délai.

Nombre minimum de transactions ouvertes en même temps avant d'attendre le délai commit_delay. Une valeur plus importante rend plus probable le fait qu'au moins une autre transaction sera prête à valider pendant la durée du délai. La valeur par défaut est de cinq.

Distance maximum entre des points de vérifications automatiques des WAL, dans les segments des journaux de traces (chaque segment fait normalement 16 Mo). Par défaut, il y en a trois. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf.

Temps maximum entre des points de vérification automatiques des WAL en secondes. La valeur par défaut est de 300 secondes. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf.

Écrit un message dans les journaux du serveur si les points de vérification causées par le remplissage des fichiers segment sont arrivés dans un intervalle plus rapide que ce nombre de secondes. Vaut par défaut 30 secondes. Une valeur de zéro désactive cet avertissement.

La commande shell pour exécuter l'archivage d'un segment complet de fichier WAL. Si cette chaîne est vide (valeur par défaut), l'archivage des WAL est désactivé. Tout %p dans la chaîne est remplacé par le chemin absolu vers le fichier à archiver et tout %f est seulement remplacé par le nom du fichier. Utilisez %% pour intégrer un vrai caractère % dans la commande. Pour plus d'informations, voir la Section 22.3.1. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

Il est important que la commande renvoie un code de sortie zéro si et seulement si elle a réussi. Exemples :

archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows

Active ou désactive l'utilisation des agrégats hachés par le planificateur. Actif par défaut.

Active ou désactive l'utilisation des jointures hachées par le planificateur. Actif par défaut.

Active ou désactive l'utilisation des parcours d'index par le planificateur. Actif par défaut.

Active ou désactive l'utilisation des jointures de fusion par le planificateur. Actif par défaut.

Active ou désactive l'utilisation des jointures de boucles imbriquées par le planificateur. Il n'est pas possible de supprimer les jointures de boucles imbriquées complètement mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.

Active ou désactive l'utilisation des parcours séquentiel par le planificateur. Il n'est pas possible de supprimer complètement les parcours séquentiels mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.

Active ou désactive l'utilisation des étapes de tri explicite par le planificateur. Il n'est pas possible de supprimer complètement ces tris mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.

Active ou désactive l'utilisation des parcours de TID par le planificateur. Actif par défaut.

Configure l'idée du planificateur sur la taille réelle du cache disque disponible pour un simple parcours d'index. Ceci est factorisé en estimation du coût d'utilisation d'un index ; une valeur plus grande rend un parcours d'index plus probable, une valeur plus basse favorise le parcours séquentiel. Lors de la modification de ce paramètre, vous devez considérer les tampons partagés de PostgreSQL et la partie cache disque du noyau qui seront utilisés pour les fichiers de données de PostgreSQL. De plus, prenez en compte le nombre attendu de requêtes concurrentes utilisant différents index car elles devront partager l'espace disponible. Ce paramètre n'a pas d'effet sur la taille de la mémoire partagée allouée par PostgreSQL, pas plus qu'il ne réserve de cache disque du noyau ; c'est utilisé uniquement dans un but d'estimation. La valeur est mesurée en pages disque, qui sont normalement de 8192 octets chaque. La valeur par défaut est de 1000.

Initialise l'estimation du coût du planificateur pour une page disque récupérée de façon non séquentielle. C'est mesuré comme un multiple du coût de récupération d'une page séquentielle. Une valeur plus haute rend plus probable l'utilisation d'un parcours séquentiel, une valeur basse l'utilisation d'un parcours d'index. La valeur par défaut est quatre.

Initialise l'estimation du coût du planificateur pour le traitement de chaque ligne lors d'une requête. C'est mesuré comme une fraction du coût de la récupération séquentielle d'une page. La valeur par défaut est 0,01.

Initialise l'estimation du coût du planificateur pour le traitement de chaque ligne lors d'un parcours d'index. C'est mesuré comme une fraction du coût de la récupération séquentielle d'une page. La valeur par défaut est 0,001.

Initialise l'estimation du coût du planificateur de requêtes pour le traitement de chaque opérateur dans une clause WHERE. C'est mesuré comme une fraction du coût de récupération séquentielle d'une page. La valeur par défaut est 0,025.

Active ou désactive l'optimisation génétique des requêtes, algorithme tentant de faire de la planification de requêtes sans recherche exhaustive. Activé par défaut. La variable geqo_threshold fournit un moyen plus fin pour désactiver certaines classes de requêtes.

Utilise l'optimisation génétique des requêtes pour planifier les requêtes avec au moins ce nombre d'éléments impliqués dans la clause FROM (notez qu'une construction JOIN externe compte seulement comme un élément du FROM). La valeur par défaut est de 12. Pour des requêtes simples, il est généralement préférable d'utiliser le planificateur déterministe, exhaustif mais pour les requêtes comprenant beaucoup de tables, le planificateur déterministe prendrait trop de temps.

Contrôle l'équité entre le temps de planification et l'efficacité du plan de requête dans GEQO. Cette variable doit être un entier entre 1 et 10. La valeur par défaut est 5. Les valeurs plus importantes augmentent le temps passé pendant la planification de la requête mais augmentent aussi la possibilité qu'un plan de requête efficace soit choisi.

geqo_effort ne fait réellement rien directement ; c'est seulement utilisé pour calculer les valeurs par défaut des autres variables qui influencent le comportement de GEQO (décrit ci-dessous). Si vous préférez, vous pouvez configurer les autres paramètres manuellement.

Contrôle la taille de la queue utilisée par GEQO. Cette taille est le nombre d'individus dans une population génétique. Elle doit être d'au moins deux, et les valeurs utiles sont typiquement 100 et 1000. Si elle est configurée à zéro (la valeur par défaut), alors une valeur par défaut convenable est choisie suivant geqo_effort et le nombre de tables dans la requête.

Contrôle le nombre de générations utilisé par GEQO. Les générations spécifient le nombre d'itérations de l'algorithme. Il doit être au moins un, et les valeurs utiles sont dans la même échelle que la taille de la queue. S'il est configuré à zéro (la valeur par défaut), alors une version par défaut convenable est choisie suivant geqo_pool_size.

Contrôle le biais de sélection utilisé par GEQO. C'est une pression sélective à l'intérieur de la population. Les valeurs peuvent aller de 1,50 à 2,00 ; ce dernier est la valeur par défaut.

Initialise la cible par défaut des statistiques pour les colonnes de table qui n'ont pas une cible spécifique de colonne configurée via ALTER TABLE SET STATISTICS. Des valeurs plus importantes accroissent le temps nécessaire à exécuter ANALYZE mais pourrait améliorer les estimations du planificateurs. La valeur par défaut est de 10. Pour plus d'informations sur l'utilisation des statistiques par le planificateur de requêtes de PostgreSQL, référez-vous à la Section 13.2.

Le planificateur assemblera les sous-requêtes dans des requêtes supérieures si la liste FROM résultante n'aurait pas plus de ce nombre d'éléments. Des valeurs plus petites réduisent le temps de planification mais ramènent des plans de requêtes inférieurs. La valeur par défaut est huit. Il est généralement conseillé de conserver cette valeur inférieure à geqo_threshold.

Le planificateur réécrira les constructions JOIN internes explicites en listes d'éléments FROM à chaque fois qu'une liste d'au plus ce nombre d'éléments au total en résulterait. Avant PostgreSQL 7.4, les jointures spécifiées via la construction JOIN ne seraient jamais réordonnées. Le planificateur de la requête a du coup été amélioré pour que les jointures internes écrites de cette forme puissent être ré-ordonnées ; ce paramètre de configuration contrôle à quel point ce ré-ordonnancement sera réalisé.

Par défaut, cette variable est configurée de la même façon que from_collapse_limit, qui est approprié pour la plupart des utilisations. Configurer cette variable à 1 empêche le réordonnancement des JOINtures internes. Du coup, l'ordre de jointure explicite spécifiée dans la requête sera l'ordre réel dans lequel les relations sont jointes. Le planificateur de la requête ne choisit pas toujours l'ordre de jointure optimal ; les utilisateurs avancées pourraient choisir d'initialiser temporairement cette variable à 1, puis de spécifier l'ordre de jointure qu'ils désirent explicitement. Une autre conséquence en l'initialisant à 1 est que le planificateur de requêtes se comporte plus comme le planificateur de requête de PostgreSQL 7.3, ce que certains utilisateurs trouvent utile pour des raisons de compatibilités descendantes.

Configurer cette variable à une valeur entre 1 et from_collapse_limit pourrait être utile pour négocier entre le temps de planification et la qualité du plan choisie (les grandes valeurs produisent les meilleures plans).

PostgreSQL supporte plusieurs méthodes pour la journalisation des messages du serveur, dont stderr et syslog. Sur Windows, eventlog est aussi supporté. Configurez cette option avec une liste de destinations désirées pour les journaux, séparées par des virgules. Par défaut, les traces vont seulement sur stderr. Cette option est seulement disponible au lancement du serveur et dans le fichier de configuration de postgresql.conf.

Cette option autorise la capture et la redirection des messages envoyés vers stderr dans des journaux de traces. Cette option, en combinaison avec les traces stderr, est souvent plus utile que de tracer dans syslog car certains types de messages pourraient ne pas apparaître dans la sortie syslog (un exemple habituel concerne les messages d'échecs de l'éditeur de liens). Cette option est seulement disponible au lancement du serveur.

Quand redirect_stderr est activé, cette option détermine le répertoire dans lequel les fichiers de trace seront créés. Elle pourrait être spécifiée avec un chemin absolu ou relatif au répertoire des données du groupe. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

Quand redirect_stderr est activé, cette option initialise les noms des fichiers des journaux créés. La valeur est traitée comme un modèle strftime, du coup les échappements % peuvent être utilisés pour spécifier des noms de fichiers dépendant de l'heure. Si aucun échappement % n'est présent, PostgreSQL ajoutera l'époque de l'heure d'ouverture du nouveau journal. Par exemple, si log_filename valait server_log, alors le nom de fichier choisi serait server_log.1093827753 pour un journal commençant le dimanche 29 août 19:02:33 2004 MST. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

Quand redirect_stderr est activé, cette option détermine la durée de vie maximum d'un journal individuel. Après que cette durée se soit écoulée, un nouveau journal sera créé. Initialisez-la à zéro pour désactiver la création des nouveaux journaux suivant un délai. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

Quand redirect_stderr est activé, cette option détermine la taille maximum d'un journal individuel. Après ce nombre d'octets, un nouveau journal est créé. Initialiser cette taille à zéro désactive la création de nouveaux journaux suivant leur taille. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

Quand redirect_stderr est activé, cette option fera que PostgreSQL tronque (surcharge), plutôt qu'il n'ajoute à un journal de même nom. Néanmoins, ce tronquage ne surviendra qu'à partir du moment où un nouveau fichier sera ouvert à cause d'une rotation basée sur le temps, et non pas suite au lancement du serveur ou suite à une rotation basée sur la taille. Si false, les fichiers déjà existants se verront ajoutés les nouvelles traces dans tous les cas. Par exemple, en utilisant cette option en combinaison avec un log_filename comme postgresql-%H.log résulterait en la génération de 24 journaux (un pour chaque heure) puis les surchargera cycliquement. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

Exemple : pour conserver sept jours de traces, un fichier par jour nommé server_log.Mon, server_log.Tue, etc. et surcharger automatiquement les traces de la semaine dernière avec ceux de cette semaine, configurez log_filename à server_log.%a, log_truncate_on_rotation à true et log_rotation_age à 1440.

Exemple : pour conserver 24 heures de traces, un journal par heure mais aussi, faire une rotation plus souvent si le journal dépasse 1 Go, configurez log_filename à server_log.%H%M, log_truncate_on_rotation à true, log_rotation_age à 60 et log_rotation_size à 1000000. Inclure %M dans log_filename permet des rotations conduites par la taille qui pourraient survenir pour sélectionner un nom de fichier différent du nom de fichier initial.

Lors que les traces syslog sont activées, cette option détermine le niveau (<< facility >>) utilisé par syslog. Vous pouvez choisir entre LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 ; la valeur par défaut est LOCAL0. Voir aussi la documentation du démon syslog de votre serveur. Cette option ne se configure qu'au lancement du système.

Si syslog est activé, cette option détermine le nom du programme utilisé pour identifier les messages de PostgreSQL dans les journaux de traces de syslog. La valeur par défaut est postgres. Cette option ne se configure qu'au lancement du système.

Contrôle les niveaux des messages envoyés au client. Les valeurs valides peuvent être DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING et ERROR. Chaque niveau inclut tous les niveaux qui le suivent. La valeur par défaut est NOTICE. Notez que LOG a un niveau différent que dans log_min_messages.

Contrôle les niveaux des messages écrits dans les journaux de traces. Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL et PANIC. Chaque niveau inclut tous les niveaux qui le suivent. Le niveau le plus bas obtient le plus petit nombre de messages. La valeur par défaut est NOTICE. Notez que LOG a un niveau différent que dans client_min_messages. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Contrôle le nombre de détails écrits dans les journaux de traces pour chaque message tracé. Les valeurs valides sont TERSE, DEFAULT et VERBOSE, chacune ajoutant plus de champs aux messages affichés. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Contrôle si l'instruction SQL ayant causé une erreur sera aussi enregistrée dans le journal des traces. Toutes les instructions SQL, qui causent une erreur du niveau spécifié ou d'un niveau plus haut, seront tracées. La valeur par défaut est PANIC (désactivant réellement cette fonctionnalité en production). Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, FATAL et PANIC. Par exemple, si vous l'initialisez à ERROR, alors toutes les instructions SQL causant des erreurs, fatales ou non, ou des paniques seront tracées. Activer cette option est utile pour localiser la source de toute erreur apparaissant dans le journal des traces. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Initialise un temps d'exécution minimum (en millisecondes) pour que l'instruction soit tracée. Toutes les instructions SQL exécutées dans le temps imparti ou prenant plus de temps seront tracées avec leur durée. L'initialiser à zéro tracera toutes les requêtes avec leur durée. -1 (la valeur par défaut) désactive cette fonctionnalité. Par exemple, si vous la configurez à 250, toutes les instructions SQL s'exécutant en au moins 250 ms seront tracées. Activer cette option peut se révéler utile pour tracer les requêtes non optimisées dans vos applications. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Exécute le serveur silencieusement. Si cette option est configurée, le serveur se lancera automatiquement en tâche de fond et tout terminal de contrôle sera dissocié (même effet que l'option -S de postmaster). La sortie standard et la sortie standard des erreurs du serveur sont redirigées vers /dev/null, donc tout message qui leur est adressé sera perdu. Sauf si le journal syslog est sélectionné ou que redirect_stderr est activé, utiliser cette option n'est pas encouragé car il empêche de voir les messages d'erreurs.

Fournit des informations utiles aux développeurs.

Fournit des informations implicitement demandées par l'utilisateur, par exemple lors d'un VACUUM VERBOSE.

Fournit des informations qui pourraient être utiles aux utilisateurs, par exemple lors du tronquage d'identifiants longs ou la création d'index faisant partie de clés primaires.

Fournit des avertissements aux utilisateurs, par exemple un COMMIT en dehors d'un bloc de transactions.

Rapporte une erreur qui a annulé la commande en cours.

Rapporte des informations intéressant les administrateurs, par exemple l'activité des points de vérification.

Rapporte une erreur qui a causé l'annulation de la session courante.

Rapporte une erreur qui a causé l'annulation de toutes les sessions.

Ces options activent plusieurs sorties de débogage. Pour chaque requête exécutée, elles affichent l'arbre d'analyse résultant. debug_pretty_print indente ces affichages pour produire un format de sortie plus lisible mais plus long. client_min_messages ou log_min_messages doivent valoir DEBUG1 ou plus bas pour réellement envoyer cette sortie vers le client ou les traces du serveur, respectivement. Ces options sont désactivées par défaut.

Ceci affiche une ligne dans les traces du serveur détaillant chaque connexion réussie. Désactivée par défaut, elle est probablement très utile. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.

Ceci affiche dans les journaux du serveur une ligne similaire à log_connections mais à la fin d'une session et inclut la durée de la session. Elle est désactivée par défaut. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.

Fait que la durée d'une instruction terminée satisfaisant log_statement est tracée. En utilisant cette option, si vous n'utilisez pas syslog, il est recommandé que vous traciez le PID ou l'ID de la session en utilisant log_line_prefix, de façon à ce que vous puissiez lier l'instruction à la durée en utilisant l'ID du processus ou de la session. Cette variable est désactivée par défaut. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Ceci est une chaîne style printf qui est affichée au début de chaque ligne de trace. La valeur par défaut est une chaîne vide. Chaque échappement reconnu est remplacé comme indiqué ci-dessous - tout ce qui reste et qui ressemble à un échappement est ignoré. Les autres caractères sont copiés directement sur la ligne. Certains échappements sont seulement reconnus par les processus de session et ne s'appliquent pas aux processus en tâche de fond comme le postmaster. Syslog produit son propre marquage horaire et informations d'ID sur le processus, donc vous ne voudrez probablement pas utiliser ces échappements si vous utilisez syslog. Cette option est seulement disponible au lancement du serveur et dans le fichier de configuration postgresql.conf.

Contrôle les instructions SQL tracées. Les valeurs valides sont none, ddl, mod et all. ddl trace toutes les commandes de définition comme CREATE, ALTER et DROP. mod trace toutes les instructions ddl, plus INSERT, UPDATE, DELETE, TRUNCATE et COPY FROM. Les instructions PREPARE et EXPLAIN ANALYZE sont aussi tracées si leur commande contenue est d'un type approprié.

La valeur par défaut est none. Seuls les superutilisateurs peuvent changer ce paramétrage.

Par défaut, les messages de traces de connexion affichent seulement l'adresse IP de l'hôte se connectant. Activer cette option causera la trace du nom de l'hôte. Notez que, suivant votre configuration de résolution de nom d'hôte, ceci pourrait imposer une pénalité de performance non négligeable. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

Pour chaque requête, écrit les statistiques de performance du module respectif dans les journaux de trace. Ceci est un outil brut de profilage. log_statement_stats rapporte les statistiques totales sur les instructions alors que les autres rapportent des statistiques par module. log_statement_stats ne peut pas être activé avec toute option par module. Toutes ces options sont désactivées par défaut. Seuls les superutilisateurs peuvent modifier ces paramétrages.

Contrôle si le serveur doit lancer le sous-processus de récupération de statistiques. Il est activé par défaut mais pourrait être enlevé si vous n'avez aucun intérêt dans la récupération de statistiques.

Active la récupération de statistiques sur les commandes en cours d'exécution par chaque session, avec le moment de l'exécution de la commande. Cette option est désactivée par défaut. Notez que, même après son activation, cette information n'est pas visible par tous les utilisateurs, mais seulement par les superutilisateurs et l'utilisateur possédant la session. Donc, cela ne devrait pas représenter un risque de sécurité. La donnée est accessible via la vue système pg_stat_activity ; référez-vous au Chapitre 23 pour plus d'informations.

Active la récupération des statistiques au niveau bloc sur l'activité de la base de données. Cette option est désactivée par défaut. Si cette option est activée, les données produites sont accessibles via la famille de vues système pg_stat et pg_statio ; référez-vous au Chapitre 23 pour plus d'informations.

Active la récupération de statistiques au niveau ligne sur l'activité de la base de données. Cette option est désactivée par défaut. Si cette option est activée, les données produites sont accessibles via la famille de vues système pg_stat et pg_statio ; référez-vous au Chapitre 23 pour plus d'informations.

Si elle est activée, les statistiques récupérées sont vidées à chaque fois que le serveur est redémarré. Dans le cas contraire, les statistiques sont cumulées après les redémarrages de serveur. Actif par défaut. Cette option peut seulement être configuré au lancement du serveur.

Cette variable spécifie l'ordre dans lequel les schémas sont recherchés lorsqu'un objet (table, type de données, fonction, etc.) est référencé par un simple nom sans son composant schéma. Quand il existe des noms identiques dans différents schémas, le premier trouvé dans le chemin de recherche est utilisé. Un objet qui ne fait partie d'aucun des schémas du chemin de recherche peut seulement être référencé en spécifiant son schéma conteneur avec un nom qualifié.

La valeur de search_path doit être 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 ayant le nom renvoyé par SESSION_USER est substitué, si un tel schéma existe (sinon $user est ignoré).

Le schéma du catalogue système, pg_catalog, est toujours recherché, qu'il soit ou non mentionné dans le chemin. S'il est mentionné, alors il sera cherché dans l'ordre spécifié. Si pg_catalog ne fait pas partie du chemin, alors il sera cherché avant tout élément du chemin.

De même, la recherche des schémas passe toujours par le schéma des tables temporaires, pg_temp_nnn, si ce dernier existe. Il est toujours possible de l'ajouter dans le chemin en utilisant l'alias pg_temp. S'il ne fait pas partie du chemin, la recherche commencera 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 sera recherché.

Lorsque des objets sont créés sans spécifier un 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' (où la deuxième partie sera ignorée s'il n'existe pas de schéma nommé public). Elle supporte l'utilisation partagée d'une base de données (où aucun utilisateur n'a de schémas privés et tous partagent l'utilisation de public), de schémas privés par utilisateur et une combinaison des deux. D'autres effets peuvent être obtenus en modifiant le chemin de recherche par défaut soit globalement soit par utilisateur.

La valeur réelle actuelle du chemin de recherche peut être examinée via la fonction SQL current_schemas(). Elle n'est pas identique à la valeur de search_path, car current_schemas() affiche comment la requête apparaissant dans search_path sera résolue.

Pour plus d'informations sur la gestion des schémas, voir la Section 5.8.

Cette variable spécifie le tablespace par défaut dans lequel créé les objets (tables et index) quand une commande CREATE ne spécifie par explicitement un tablespace.

La valeur est soit le nom de le tablespace soit une chaîne vide pour indiquer l'utilisation de le tablespace par défaut de la base de données en cours. Si la valeur ne correspond pas au nom d'une base de données existantes, PostgreSQL utilisera automatiquement le tablespace par défaut de la base de données en cours.

Pour plus d'informations sur les espaces logiques, voir la Section 18.6.

Ce paramètre est habituellement à true. Lorsqu'il vaut false, il désactive la validation de la chaîne du corps de la fonction lors de CREATE FUNCTION. Désactiver la validation est quelque fois utile pour éviter des problèmes tels que les références avant lors de la restauration des définitions de fonctions à partir d'une sauvegarde.

Chaque transaction SQL a un niveau d'isolation, qui peut être soit << read uncommitted >>, soit << read committed >>, soit << repeatable read >> soit << serializable >>. Ce paramètre contrôle le niveau d'isolation par défaut de chaque nouvelle transaction. Par défaut, << read committed >>.

Consultez Chapitre 12 et SET TRANSACTION pour plus d'informations.

Une transaction SQL en lecture seule ne pourrait pas modifier les tables non temporaires. Ce paramètre contrôle le statut de lecture seule par défaut de chaque nouvelle transaction. La valeur par défaut est faux (lecture/écriture).

Consultez SET TRANSACTION pour plus d'informations.

Annule toute instruction prenant plus que le nombre spécifié de millisecondes. Une valeur de zéro désactive le chronomètre et est la valeur par défaut.

Configure le format d'affichage pour les valeurs de type date et heure, ainsi que les règles d'interprétation des valeurs de saisie des dates ambiguës. Pour des raisons historiques, cette variable contient deux composants indépendants : la spécification du format en sortie (ISO, Postgres, SQL ou German) et la spécification en entrée/sortie pour 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 un synonyme pour DMY ; les mots clés US, NonEuro et NonEuropean sont des synonymes pour MDY. Voir la Section 8.5 pour plus d'informations. La valeur par défaut est ISO, MDY.

Configure le fuseau horaire pour l'affichage et l'interprétation de la date et de l'heure. Par défaut, vaut 'unknown', ce qui signifie qu'il utilise ce que l'environnement système spécifie comme fuseau horaire. Voir la Section 8.5 pour plus d'informations.

Si vrai, ACST, CST, EST et SAT sont interprétés comme des fuseaux horaires australiens plutôt que comme des fuseaux horaires d'Amérique Nord/Sud. Par défaut à faux.

Ce paramètre ajuste le nombre de chiffres affichés par les valeurs à virgule flottante, ceci incluant float4, float8 et les types de données géométriques. La valeur du paramètre est ajouté au nombre standard de chiffres (FLT_DIG ou DBL_DIG comme approprié). La valeur peut être initialisée à une valeur maximum de 2 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.

Initialise le codage côté client (ensemble de caractères). Par défaut, utilise le codage de la base de données.

Initialise la langue dans laquelle les messages sont affichés. Les valeurs acceptables sont dépendantes du système ; voir Section 20.1 pour plus d'informations. Si cette variable est initialisée en tant que chaîne vide (ce qui est la 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 fonctionnera toujours mais n'aura aucun effet. De même, il existe une chance pour qu'aucun message traduit n'existe pour la langue sélectionnée. Dans ce cas, vous continuerez de voir les messages en anglais.

Initialise la locale à utiliser pour formater les montants de monnaie, par exemple avec la famille de fonctions to_char. Les valeurs acceptables dépendent du système ; voir la Section 20.1 pour plus d'informations. Si cette variable est une chaîne vide (la valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.

Initialise la locale à utiliser pour formater les nombres, par exemple avec la famille de fonctions to_char. Les valeurs acceptables dépendent du système ; voir la Section 20.1 pour plus d'informations. Si cette variable est 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 formater les valeurs de date et d'heure (actuellement, ce paramétrage ne fait rien mais il le pourrait dans le futur). Les valeurs acceptables dépendent du système ; voir la Section 20.1 pour plus d'informations. Si cette variable est une chaîne vide (la valeur par défaut), alors la valeur est héritée de l'environnement système du serveur.

Détermine si EXPLAIN VERBOSE utilise le format indenté ou non pour l'affichage des arbres détaillés des requêtes. Activé par défaut.

Si un module chargeable dynamiquement a besoin d'être ouvert et que le nom de fichier spécifié dans la commande CREATE FUNCTION ou LOAD ne contient pas de répertoire (c'est-à-dire que le nom ne contient pas de slash), le système cherchera ce chemin pour le fichier requis.

La valeur pour 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 commence avec 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 (utilisez pg_config --pkglibdir pour 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 paramétrage réalisé de cette façon ne persistera que pendant la durée de la connexion du client, donc cette méthode devrait être réservée à des buts de développements. La façon recommandée pour initialiser ce paramètre est d'utiliser le fichier de configuration postgresql.conf.

Si true, les tables qui sont référencées par une requête seront automatiquement ajoutées dans la clause FROM si elles n'y sont pas déjà présentes. La valeur par défaut est true pour des raisons de compatibilité avec les versions précédentes de PostgreSQL. Néanmoins, ce comportement n'appartient pas au standard SQL et beaucoup de personnes ne l'aiment pas car elle peut masquer les erreurs (comme référencer une table où vous devriez avoir référencé son alias). L'initialiser à false pour avoir un comportement en compatibilité avec le standard SQL permet de rejeter les références non listés dans la clause FROM.

Ceci contrôle si un guillemet peut être représenté par un \' dans une chaîne. Le moyen préféré, standard SQL, pour représenter un guillemet est de le doubler ('') mais, historiquement, PostgreSQL accepte aussi \'. Néanmoins, l'utilisation de \' ajoute des problèmes liés à la sécurité car certains codages d'ensembles de caractères des clients contiennent des caractères multi-octets dans lesquel le dernier octet est l'équivant ASCII numérique d'un \. Si le code côté client ne fait pas un échappement correct, alors une attaque par injection SQL est possible. Ce risque peut être annihilé en s'assurant que le serveur rejette les requêtes dans lesquelles apparait un guillemet à échapper avec un antislash. Les valeurs autorisées de backslash_quote sont on (autorise \' en permanence), off (rejette en permanence) et safe_encoding (l'autorise seulement si le codage du client n'autorise pas l'ASCII \ dans un caractère multioctet). safe_encoding est le paramétrage par défaut.

Elle contrôle si les commandes CREATE TABLE et CREATE TABLE AS incluent une colonne OID dans les tables nouvellement créées, si ni WITH OIDS ni WITHOUT OIDS ne sont spécifiées. Elle détermine aussi si les OID seront inclus dans les tables créés par SELECT INTO. Dans PostgreSQL 8.0.25, la valeur par défaut de default_with_oids est true. C'est aussi le comportement des versions précédentes de PostgreSQL. Néanmoins, supposer que les tables contiendront des OID par défaut n'est pas encouragé. Cette option aura probablement la valeur false par défaut dans une future version de PostgreSQL.

Pour faciliter la compatibilité avec les applications utilisant les OID, cette option devrait être activée. Pour faciliter la compatibilité avec les futures versions de PostgreSQL, cette option devrait être désactivée et les applications réclamant des OID sur certaines tables devraient spécifier explicitement WITH OIDS lors de la création de ces tables.

La << saveur >> des expressions rationnelles peut être advanced (avancée), extended (étendue) ou basic (basique). La valeur par défaut est advanced. Le paramétrage extended peut être utile pour une compatibilité ascendante exacte avec les versions précédant la 7.4 de PostgreSQL. Voir la Section 9.7.3.1 pour les détails.

Ceci contrôle la sémantique de l'héritage, en particulier si les sous-tables sont incluses par les différentes commandes par défaut. Elles ne l'étaient pas dans les versions antérieures à la 7.1. Si vous avez besoin de l'ancien comportement, vous pouvez désactiver cette variable mais, à long terme, vous êtes encouragé à changer vos applications pour utiliser le mot clé ONLY qui exclut les sous-tables. Voir la Section 5.5 pour plus d'informations sur les héritages.

Une fois activée, les expressions de la forme expr = NULL (ou NULL = expr) sont traitées comme expr IS NULL, c'est-à-dire qu'elles renvoient vrai si expr s'évalue par la valeur NULL, et faux sinon. Le bon comportement, compatible avec le standard SQL, de expr = NULL est de toujours renvoyer NULL (inconnu). Du coup, cette option est désactivée par défaut.

Néanmoins, les formulaires filtrés dans Microsoft Access génèrent des requêtes qui utilisent expr = NULL pour tester les valeurs NULL, donc si vous utilisez cette interface pour accéder à une base de données, vous souhaiterez activer cette option. Comme les expressions de la forme expr = NULL renvoient toujours la valeur NULL (en utilisant la bonne interprétation), elles ne sont pas très utiles et n'apparaissent pas souvent dans les applications normales, donc cette option a peu d'utilité en pratique. Mais les nouveaux utilisateurs confondent fréquemment la sémantique des expressions impliquant des valeurs NULL. Du coup, cette option n'est pas activée par défaut.

Notez que cette option affecte seulement la forme exacte = NULL, aucun autre opérateur de comparaison ou aucune autre expression qui sont équivalentes en terme de calcul à des expressions impliquant l'opérateur égal (telles que IN). Du coup, cette option n'est pas un correctif général pour une mauvaise programmation.

Référez-vous à la Section 9.2 pour des informations en relation.