Installe tous les fichiers dans le répertoire « PREFIX » au lieu du répertoire « /usr/local/pgsql ». Les fichiers eux-mêmes seront installés dans divers sous-répertoires ; aucun fichier ne sera directement installé sous « PREFIX ».

Les fichiers qui dépendent de l'architecture peuvent être installés dans un répertoire avec un préfixe différent, « EXEC-PREFIX », différent de celui donné par « PREFIX ». Cela peut être utile pour partager entre plusieurs machines les fichiers indépendants de l'architecture. S'il est omis, « EXEC-PREFIX » est égal à « PREFIX », et les fichiers dépendants seront installés sous la même arborescence que les fichiers indépendants de l'architecture, ce qui est probablement le but recherché.

Indique le répertoire des exécutables. Par défaut, il s'agit de « EXEC-PREFIX/bin », ce qui signifie « /usr/local/pgsql/bin ».

Précise le répertoire de divers fichiers de configuration, par défaut « PREFIX/etc ».

Précise le répertoire d'installation des bibliothèques et des modules chargeables dynamiquement. Par défaut, il s'agit de « EXEC-PREFIX/lib ».

Précise le répertoire d'installation des fichiers d'en-tête C et C++. Par défaut, il s'agit de « PREFIX/include ».

Indique le répertoire racine de différents types de fichiers de données en lecture seule. Cela ne sert qu'à paramétrer des valeurs par défaut pour certaines des options suivantes. La valeur par défaut est « PREFIX/share ».

Indique le répertoire pour les fichiers de données en lecture seule utilisés par les programmes installés. La valeur par défaut est « DATAROOTDIR ». NB : cela n'a aucun rapport avec l'endroit où les fichiers de base de données seront placés.

Indique le répertoire pour installer les données de localisation, en particulier les fichiers des catalogues de traduction des messages. La valeur par défaut est « DATAROOTDIR/locale ».

Les pages de manuel fournies avec PostgreSQL seront installées sous ce répertoire, dans leur sous-répertoire « manx » respectif. Par défaut, il s'agit de « DATAROOTDIR/man ».

Configure le répertoire racine pour installer les fichiers de documentation, sauf les pages « man ». Ceci ne positionne la valeur par défaut que pour les options suivantes. La valeur par défaut pour cette option est « DATAROOTDIR/doc/postgresql ».

La documentation de PostgreSQL, formatée en HTML, sera installée dans ce répertoire. La valeur par défaut est « DATAROOTDIR ».

Active le support des langues natives (NLS), c'est-à-dire la capacité d'afficher les messages d'un programme dans une langue autre que l'anglais. « LANGUES » est une liste optionnelle des codes de langue que vous voulez supporter, séparés par une espace ; par exemple, --enable-nls='de fr' (l'intersection entre la liste et l'ensemble des langues traduites actuellement sera calculée automatiquement). En l'absence de liste, toutes les traductions disponibles seront installées.

Pour utiliser cette option, une implémentation de l'API Gettext est nécessaire.

Permet la compilation du langage côté serveur PL/Perl

Permet la compilation du langage côté serveur PL/Python.

Permet la compilation du langage côté serveur PL/Tcl.

Tcl installe le fichier « tclConfig.sh », qui contient des informations de configuration nécessaires pour compiler le module d'interfaçage avec Tcl. Ce fichier est normalement trouvé automatiquement à un emplacement connu, mais pour utiliser une version différente de Tcl, il faut indiquer le répertoire où chercher « tclConfig.sh ».

Compiler avec le support de la bibliothèque ICU, activant les collations ICU . Le paquet ICU4C doit être installé. Sa version minimum nécessaire est actuellement la 4.2.

Par défaut, pkg-config sera utilisé pour déterminer les options de compilation nécessaires. Cela est supporté pour ICU4C version 4.6 et suivantes. Pour des versions plus anciennes, ou si pkg-config n'est pas disponible, les variables ICU_CFLAGS et ICU_LIBS peuvent être fournies à « configure », comme dans cet exemple :

./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-L/some/where/lib -licui18n -licuuc -licudata'
      

(Si ICU4C est dans le chemin par défaut du compilateur, vous aurez besoin de préciser des chaînes non vides pour éviter l'appel à pkg-config, par exemple ICU_CFLAGS=' '.)

Compile avec le support de JIT, basé sur LLVM . Ceci nécessite l'installation de la bibliothèque LLVM. Sa version minimale requise est actuellement la 3.9.

« llvm-config » sera utilisé pour trouver les options de compilation nécessaires. « llvm-config », puis « llvm-config-$major-$minor » pour toutes les versions supportées, seront recherchés dans votre PATH. Au cas où le bon programme n'est pas trouvé, il faut utiliser la variable LLVM_CONFIG pour spécifier le chemin du bon « llvm-config ». Par exemple :

./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'
      

Le support de LLVM nécessite un compilateur « clang » compatible (à spécifier, si nécessaire, avec la variable d'environnement CLANG), et un compilateur C++ fonctionnel (à spécifier, si nécessaire, avec la variable d'environnement CXX).

Compile avec le support de la compression LZ4.

Compile avec le support de la compression Zstandard.

Compile avec le support pour les connexions SSL (avec chiffrement). Le seul « LIBRARY » supporté est « openssl ». Ceci nécessite que le paquet OpenSSL soit installé. « configure » vérifiera les fichiers d'en-tête et les bibliothèques pour s'assurer que votre installation d'OpenSSL est suffisante avant de continuer.

Équivalent obsolète de --with-ssl=openssl.

Compile avec le support de l'authentification GSSAPI. Sur beaucoup d'environnements, le système GSSAPI (habituellement une partie de l'installation Kerberos) n'est pas installé dans un endroit recherché par défaut (par exemple « /usr/include » ou « /usr/lib ») ; vous devez donc ajouter aussi les options « --with-includes » et « --with-libraries ». « configure » vérifiera les fichiers d'en-tête et les bibliothèques pour s'assurer que votre installation de GSSAPI est suffisante avant de continuer.

Compile avec le support de LDAP pour l'authentification et la recherche des paramètres de connexion . Sur Unix, cela requiert l'installation du paquet OpenLDAP. Sur Windows, la bibliothèque WinLDAP est utilisée par défaut. « configure » vérifiera l'existence des fichiers d'en-tête et des bibliothèques nécessaires pour s'assurer que votre installation d'OpenLDAP est suffisante avant de continuer.

Compile avec le support de PAM (Pluggable Authentication Modules).

Compile avec le support de l'authentification BSD. (Le framework BSD Authentication n'est actuellement disponible que sur OpenBSD.)

Compile avec le support du système de notifications systemd. Ceci améliore l'intégration si le serveur est démarré par systemd, mais n'a pas d'impact sinon. libsystemd et les fichiers d'en-tête associés doivent être installés pour utiliser cette option.

Compile avec le support du service de découverte automatique Bonjour. Cela nécessite le support de Bonjour dans votre système d'exploitation. Recommandé sur macOS.

Compile le module uuid-ossp (qui fournit des fonctions pour générer des UUID), en utilisant la bibliothèque UUID spécifiée. « LIBRARY » doit correspondre à une de ces valeurs :

Équivalent obsolète de --with-uuid=ossp.

Compile avec libxml2, activant ainsi le support de SQL/XML. Une version 2.6.23 ou ultérieure de libxml2 est requise pour cette fonctionnalité.

Pour détecter les options requises pour le compilateur et l'éditeur de liens, PostgreSQL va demander à « pkg-config », s'il est installé et s'il connaît libxml2. Sinon, le programme « xml2-config », qui est installé par libxml2, sera utilisé s'il est trouvé. L'utilisation de « pkg-config » est préférée, parce qu'elle gère mieux les installations multiarchitectures.

Pour utiliser une installation libxml2 située dans un emplacement inhabituel, vous pouvez configurer les variables d'environnement relatives à « pkg-config » (voir sa documentation), ou configurer la variable d'environnement XML2_CONFIG pour qu'elle pointe sur le programme « xml2-config » appartenant à l'installation libxml2, ou configurer les variables XML2_CFLAGS et XML2_LIBS. (Si « pkg-config » est installé, alors, pour surcharger son idée de l'emplacement de libxml2, vous devez renseigner soit XML2_CONFIG, soit XML2_CFLAGS et XML2_LIBS, avec des chaînes non vides.)

Compile avec libxslt, activant le module xml2 pour opérer des transformations XSL sur du XML. « --with-libxml » doit être spécifié aussi.

Empêche l'utilisation de la bibliothèque Readline (et libedit par la même occasion). Cette option désactive l'édition de la ligne de commande et l'historique dans psql.

Favorise l'utilisation de la bibliothèque libedit (licence BSD). Cette option n'est importante que si vous avez les deux librairies installées ; le défaut dans ce cas est d'utiliser Readline.

Empêche l'utilisation de la bibliothèque Zlib. Cela désactive le support des archives compressées dans pg_dump et pg_restore.

Autorise le succès de la compilation même si PostgreSQL n'a pas le support des spinlocks pour le CPU de la plateforme. Ce manque de support entraînera des performances très faibles ; du coup, cette option ne devra être utilisée que si la compilation échoue et vous informe du manque de support des spinlocks sur votre plateforme. Si cette option est nécessaire pour y compiler PostgreSQL, merci de rapporter le problème à ses développeurs.

Désactive l'utilisation des opérations atomiques sur le CPU. Cette option ne fait rien sur les plateformes qui n'ont pas ces opérations. Sur celles qui l'ont, cela entraînera de mauvaises performances. Cette option n'est utile que pour le débogage ou pour des comparatifs de performance.

Désactive la sécurité des threads pour les bibliothèques clients. Ceci interdit aux threads concurrents dans les programmes libpq et ECPG de contrôler en toute sécurité leurs pointeurs de connexion privés. N'utiliser que sur les plateformes avec un support des threads défaillant.

« RÉPERTOIRES » est une liste de répertoires, séparés par le caractère deux points (:), qui seront ajoutés à la liste de ceux où le compilateur recherche des fichiers d'en-tête. Si vous avez des paquets optionnels (comme GNU Readline) installés dans un emplacement non conventionnel, vous devez utiliser cette option, et probablement aussi l'option correspondante « --with-libraries ».

Exemple : --with-includes=/opt/gnu/include:/usr/sup/include.

« RÉPERTOIRES » est une liste de répertoires, séparés par le caractère deux points (:), où chercher des bibliothèques de fonctions. Si vous avez des paquets installés dans des emplacements non conventionnels, vous devez utiliser cette option (et probablement aussi l'option correspondante « --with-includess »).

Exemple : --with-libraries=/opt/gnu/lib:/usr/sup/lib.

PostgreSQL inclut sa propre base de données des fuseaux horaires, nécessaire pour les opérations sur les dates et les heures. Cette base de données est en fait compatible avec la base de fuseaux horaires IANA fournie par de nombreux systèmes d'exploitation comme FreeBSD, Linux et Solaris, donc il semble redondant de l'installer une nouvelle fois. Quand cette option est utilisée, la base des fuseaux horaires fournie par le système, dans « RÉPERTOIRE », est utilisée à la place de celle incluse dans la distribution des sources de PostgreSQL. « RÉPERTOIRE » doit être indiqué avec un chemin absolu. « /usr/share/zoneinfo » est un répertoire courant sur certains systèmes d'exploitation. Notez que la routine d'installation ne détectera pas les données de fuseau horaire différentes ou erronées. Si vous utilisez cette option, il est conseillé de lancer les tests de régression pour vérifier que les données de fuseau horaire que vous pointez fonctionnent correctement avec PostgreSQL.

Cette option est surtout destinée aux distributeurs de paquets binaires, qui connaissent bien leur système d'exploitation. Le principal avantage de cette option est que le paquet de PostgreSQL n'aura pas besoin de mise à jour à chaque changement des règles des fuseaux horaires. Un autre avantage est que PostgreSQL peut être cross-compilé plus simplement si les fichiers des fuseaux horaires n'ont pas besoin d'être construits lors de l'installation.

Ajoute « CHAÎNE » au numéro de version de PostgreSQL. Par exemple, vous pouvez utiliser cela pour marquer des binaires compilés depuis des snapshots Git, ou contenant des patchs, avec une chaîne supplémentaire, comme un identifiant « git describe » ou un numéro de version de distribution du paquet.

N'indique pas aux exécutables de PostgreSQL qu'ils doivent chercher les bibliothèques partagées dans le répertoire des bibliothèques de l'installation (voir « --libdir »). Sur la plupart des plateformes, cette indication utilise un chemin absolu vers le répertoire des bibliothèques, et sera inutile si vous déplacez l'installation plus tard. Cependant, vous devrez alors fournir aux exécutables un autre moyen pour trouver les bibliothèques partagées. Typiquement, cela implique de configurer l'éditeur de liens du système d'exploitation pour les rechercher ; voir la section intitulée « Bibliothèques partagées » pour plus de détails.

Positionne « PORT » comme numéro de port pour les serveurs et les clients. Le défaut est 5432. Le port peut toujours être changé plus tard ; mais, si vous le spécifiez ici, serveur et clients auront le même défaut dès la compilation, ce qui peut être très pratique. D'habitude, la seule bonne raison de sélectionner une autre valeur que le défaut est si vous avez l'intention de faire tourner plusieurs serveurs PostgreSQL sur la même machine.

Le nom par défaut du service principal Kerberos utilisé par GSSAPI. postgres est le défaut. D'habitude, il n'y a aucune raison de changer cela, à moins que vous ne compiliez pour un environnement Windows  auquel cas ce doit être, en majuscules, POSTGRES.

Définit la taille d'un segment (segment size), en gigaoctets. Au niveau du système d'exploitation, les grandes tables sont divisées en plusieurs fichiers, chacun d'une taille égale à la taille d'un segment. Cela évite des problèmes avec les limites de taille de fichiers qui existent sur beaucoup de plateformes. La taille par défaut, 1 gigaoctet, est une valeur sûre pour toutes les plateformes supportées. Si votre système d'exploitation supporte les fichiers de grande taille (« largefile »), et la plupart le font, de nos jours, vous pouvez utiliser une plus grande taille de segment. Ce peut être utile pour réduire le nombre de descripteurs de fichiers consommés en travaillant avec de très grandes tables. Mais faites attention à ne pas choisir une valeur plus large que ce qui est supporté par votre plateforme et les systèmes de fichiers que vous voulez utiliser. D'autres outils que vous pourriez vouloir utiliser, comme tar, peuvent aussi poser des limites sur la taille de fichier utilisable. Il est recommandé que cette valeur soit une puissance de 2, même si ce n'est pas absolument nécessaire. Notez que changer cette valeur casse la compatibilité entre bases au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser « pg_upgrade » pour mettre à jour vers une version compilée avec une taille de segment différente.

Définit la taille de bloc (block size), en kilooctets. C'est l'unité de stockage et d'entrée-sortie dans les tables. Le défaut, 8 kilooctets, est adéquat pour la plupart des situations ; mais d'autres valeurs peuvent être utiles dans certains cas. La valeur peut être une puissance de 2 entre 1 et 32 (kilooctets). Notez que changer cette valeur casse la compatibilité entre bases au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser « pg_upgrade » pour mettre à jour vers une version compilée avec une taille de bloc différente.

Définit la taille de bloc dans les journaux de transaction (WAL block size), en kilooctets. C'est l'unité de stockage et d'entrée-sortie en leur sein. Le défaut, 8 kilooctets, convient pour la plupart des situations ; mais d'autres valeurs peuvent être utiles dans certains cas. La valeur doit être une puissance de 2 entre 1 et 64 (kilooctets). Notez que changer cette valeur casse la compatibilité entre bases au niveau fichier, ce qui veut dire que vous ne pouvez pas utiliser « pg_upgrade » pour mettre à jour vers une version compilée avec une taille de bloc de WAL différente.

Compile tous les programmes et bibliothèques avec les symboles de débogage. Cela signifie que vous pouvez exécuter les programmes au sein d'un débogueur pour analyser les problèmes. Cela augmente considérablement la taille des exécutables et, avec des compilateurs autres que GCC, désactive habituellement les optimisations du compilateur, provoquant des ralentissements. Cependant, avoir les symboles en place est extrêmement utile pour traiter d'éventuels problèmes. Actuellement, cette option n'est recommandée pour les installations en production que si vous utilisez GCC. Néanmoins, vous devriez toujours l'utiliser si vous développez, ou si vous utilisez une version bêta.

Active les vérifications des assertions (assertion) dans le serveur, qui testent de nombreuses conditions qui « ne peuvent pas arriver ». C'est inestimable pour le développement du code, mais les tests peuvent ralentir le serveur considérablement. Activer ces tests ne va pas améliorer la stabilité de votre serveur ! Les tests des assertions ne sont pas triés par sévérité, et un petit bug relativement inoffensif, s'il déclenche un échec d'assertion, peut mener à des redémarrages du serveur ! Cette option n'est pas recommandée en production, mais vous devriez l'avoir en développement, ou en utilisant une version bêta.

Active les tests avec les outils TAP de Perl. Cela nécessite une installation de Perl et de son module IPC::Run.

Active le suivi automatique des dépendances. Avec cette option, les makefiles sont conçus pour que tous les fichiers objets soient recompilés si n'importe quel fichier d'en-tête change. C'est utile si vous faites du développement, mais n'est que gaspillage si vous ne devez compiler qu'une fois pour installer. Pour le moment, cette option ne fonctionne qu'avec GCC.

Si vous utilisez GCC, tous les programmes et bibliothèques sont compilés avec de l'instrumentation de test de couverture de code. Quand ils sont exécutés, ils génèrent des fichiers dans le répertoire de compilation avec des métriques de couverture de code. Cette option ne doit être utilisée qu'avec GCC et en développement.

En cas d'utilisation de GCC, tous les programmes et bibliothèques sont compilés pour pouvoir être profilés. À la sortie du processus serveur, un sous-répertoire sera créé pour contenir le fichier « gmon.out » contenant les données de profilage. Cette option n'est à utiliser qu'avec GCC et en développement.

Compile PostgreSQL avec le support de l'outil de trace dynamique, DTrace.

Pour pointer vers le programme « dtrace », la variable d'environnement DTRACE peut être configurée. Ce sera souvent nécessaire, car « dtrace » est typiquement installé sous « /usr/sbin », qui peut ne pas être dans votre PATH.

Des options supplémentaires en ligne de commande pour « dtrace » peuvent être indiquées dans la variable d'environnement DTRACEFLAGS pour le programme « dtrace ». Sur Solaris, pour inclure le support de DTrace dans un exécutable 64 bits, ajoutez l'option DTRACEFLAGS="-64". Par exemple, en utilisant le compilateur GCC :

./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
      

En utilisant le compilateur de Sun :

./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...