PostgreSQL peut être compilés avec la suite de compilation Visual C++ de Microsoft. Les compilateurs peuvent être soit Visual Studio, soit Visual Studio Express soit certaines versions du Microsoft Windows SDK. Si vous n'avez pas déjà un environnement Visual Studio en place, le plus simple est d'utiliser les compilateurs de Visual Studio 2022 ou ceux du Windows SDK 10, tous les deux disponibles en téléchargement libre sur le site de Microsoft.
Compiler en 32 bits et 64 bits est possible avec la suite Microsoft Compiler. Compiler en 32 bits est possible à l'aide de Visual Studio 2015 jusqu'à Visual Studio 2022, ainsi qu'avec les versions autonomes Windows SDK, à partir de la version 10. Les compilations 64 bits sont supportées avec Microsoft Windows SDK à partir de la version 10 ou à partir de Visual Studio 2015.
   Les outils pour compiler avec Visual C++ ou
   Platform SDK sont dans le répertoire
   src\tools\msvc. Lors de la compilation, assurez-vous
   qu'il n'y a pas d'outils de MinGW ou
   Cygwin présents dans votre PATH
   système. Assurez-vous aussi que vous avez tous les outils Visual C++
   requis disponibles dans le PATH.
   Dans Visual Studio, lancez le
   Visual Studio Command Prompt. Pour compiler
   une version 64 bits, vous devez utiliser la version 64 bits, et inversement.
   À partir de Visual Studio 2017,
   ceci peut se faire à partir de la ligne de
   commande en utilisant VsDevCmd.bat (voir
   -help pour les options disponibles et leur valeurs par
   défaut). vsvars32.bat est disponible dans
   Visual Studio 2015 et les versions antérieures
   dans le même but. À partir du Visual Studio Command
    Prompt, vous pouvez modifier l'architecture CPU ciblée, le
   type de compilation, et le système d'exploitation cible grâce à la
   commande vcvarsall.bat. Par exemple,
   vcvarsall.bat x64 10.0.10240.0 ciblera Windows 10
   en 64 bits. Voir -help pour les
   autres options de vcvarsall.bat. Toutes les commandes
   doivent être exécutées à partir du répertoire
   src\tools\msvc.
  
   Avant de compiler, vous pouvez créer le fichier
   config.pl pour y modifier toutes les options de
   configuration nécessaires, ainsi que les chemins utilisés par les
   bibliothèques tierces. La configuration complète est déterminée
   tout d'abord en lisant et en analysant le fichier
   config_default.pl, puis en appliquant les
   modifications provenant du fichier config.pl. Par
   exemple, pour indiquer l'emplacement de votre installation de
   Python, placez la ligne suivante dans
   config.pl :
   
   $config->{python} = 'c:\python310';
   
   Vous n'avez besoin de spécifier que les paramètres différents
   de ceux définis dans config_default.pl.
  
   Si vous avez besoin de configurer d'autres variables d'environnement, créez
   un fichier buildenv.pl, et placez-y les
   commandes souhaitées. Par exemple, pour ajouter le chemin vers bison s'il
   ne se trouve pas dans le PATH, créez un fichier contenant :
   
   $ENV{PATH}=$ENV{PATH} . ';c:\chemin\vers\bison\bin';
   
Pour passer d'autres arguments en ligne de commande à la commande de compilation de Visual Studio (msbuild or vcbuild) :
$ENV{MSBFLAGS}="/m";
   
    Les outils suivants sont requis pour compiler
    PostgreSQL. Utilisez le fichier
    config.pl pour indiquer les chemins
    des bibliothèques.
    
Si votre environnement de compilation ne contient pas une version supportée du Microsoft Windows SDK, il est recommandé de mettre à jour vers la dernière version supportée (actuellement la 10), téléchargeable sur le site de Microsoft.
Vous devez toujours inclure la partie Windows Headers and Libraries du SDK. Si vous installez un Windows SDK incluant les Visual C++ Compilers, vous n'avez pas besoin de Visual Studio. Notez que la version 8.0a du Windows SDK ne contient plus d'environnement complet de compilation en ligne de commande.
        Strawberry Perl est requis pour exécuter les scripts de compilation.
        La commande Perl de MinGW et de Cygwin ne fonctionnera pas. Strawberry Perl
        doit aussi être présent dans le PATH. Ses binaires
        sont téléchargeables à partir du site officiel (il faut
        une version 5.14, la distribution standard libre est
        suffisante).
       
    Les produits suivants ne sont pas nécessaires pour démarrer, mais sont
    nécessaires pour construire la distribution complète. Utilisez le fichier
    config.pl pour indiquer les chemins
    des bibliothèques.
    
Nécessaire pour construire PL/Tcl. Les binaires peuvent être téléchargés à partir du site officiel.
Bison et Flex sont nécessaires pour compiler à partir de Git, mais pas pour compiler à partir d'une version distribuée. Seul Bison 2.3 et ultérieures fonctionneront. Flex doit être en version 2.5.35 ou supérieure.
Bison et Flex sont inclus dans la suite d'outils msys, disponible à partir de son site officiel, comme partie de la suite de compilation MinGW.
        Le répertoire contenant
        flex.exe et bison.exe
        devra être ajouté à la
        variable d'environnement PATH dans buildenv.pl
        s'il n'y est pas déjà. Dans le cas de MinGW, le répertoire est le
        sous-répertoire \msys\1.0\bin de votre répertoire
        d'installation de MinGW.
       
         La distribution Bison de GnuWin32 a apparemment un bug menant à un
         dysfonctionnement de Bison s'il est installé dans un répertoire
         dont le nom contient des espaces, tel que l'emplacement par défaut
         dans les installations en anglais : C:\Program
          Files\GnuWin32. Installez-le donc plutôt dans
         C:\GnuWin32, ou utilisez le chemin court NTFS de
         GnuWin32 dans votre variable d'environnement PATH (par exemple
         C:\PROGRA~1\GnuWin32).
        
Diff est nécessaire pour exécuter les tests de régression, et peut être téléchargé à partir de la page du projet gnuwin32 sur Sourceforge.
Gettext est requis pour construire le support des langues (NLS), et peut être téléchargé à partir de la page du projet gnuwin32 sur Sourceforge. Notez que les binaires, dépendances et fichiers d'en-tête sont tous nécessaires.
Requis pour le support de l'authentification GSSAPI. MIT Kerberos est téléchargeable sur le site du MIT.
Nécessaire pour le support du XML. Les binaires sont disponibles sur zlatkovic.com et les sources sur le xmlsoft.org. Notez que libxml2 nécessite iconv, disponible sur le même site.
Nécessaire pour la méthode de compression LZ4. Binaires et sources peuvent être téléchargés depuis https://github.com/lz4/lz4/releases.
Requis pour la méthode de compression Zstandard. Binaires et sources peuvent être téléchargés depuis https://github.com/facebook/zstd/releases.
Nécessaire pour le support de SSL. Les binaires peuvent être téléchargés à partir de slproweb.com, ou les sources à partir de openssl.org.
Nécessaire pour le support d'UUID-OSSP (seulement en contrib). Les sources peuvent être récupérées sur ossp.org.
Nécessaire pour la compilation de PL/Python. Les binaires sont téléchargeables sur python.org.
Nécessaire pour le support de la compression dans pg_dump et pg_restore. Les binaires sont disponibles sur le site officiel.
PostgreSQL ne peut être compilé pour l'architecture x64 que sur un Windows 64 bits.
Le mélange de versions 32 bits et de versions 64 bits dans le même répertoire de compilation n'est pas supporté. Le système de compilation détecte automatiquement si l'environnement est 32 bits ou 64 bits, et compile PostgreSQL en accord. Pour cette raison, il est important de démarrer la bonne invite de commande avant de lancer la compilation.
Pour utiliser une bibliothèque tierce côté serveur, comme Python ou OpenSSL, cette bibliothèque doit aussi être en 64 bits. Il n'y a pas de support pour le chargement d'une bibliothèque 32 bits sur un serveur 64 bits. Plusieurs bibliothèques de tierce partie que PostgreSQL supporte ne sont disponibles qu'en version 32 bits, auquel cas elles ne peuvent pas être utilisées avec un serveur PostgreSQL 64 bits.
Pour compiler tout PostgreSQL dans la configuration publiée (par défaut), exécutez la commande :
buildPour construire tout PostgreSQL dans la configuration de débogage, exécutez :
build DEBUGPour construire un seul projet, par exemple psql, exécutez l'une des deux commandes ci-dessous, suivant que vous souhaitez la configuration par défaut ou celle de débogage :
     build psql
     build DEBUG psql
    
    Pour modifier la configuration de compilation par défaut, placez ce qui
    suit dans le fichier buildenv.pl :
    
$ENV{CONFIG}="Debug";
    
Il est aussi possible de compiler à partir de l'interface graphique de Visual Studio. Dans ce cas, vous devez exécuter :
perl mkvcbuild.pl
    à partir de l'invite, puis ouvrir le fichier
    pgsql.sln généré (dans le répertoire racine des
    sources) dans Visual Studio.
   
    La plupart du temps, la récupération automatique des dépendances dans
    Visual Studio prendra en charge les fichiers modifiés. Mais, s'il y a eu
    trop de modifications, il peut y avoir besoin de nettoyer
    l'installation. Pour cela, exécutez simplement la commande
    clean.bat, qui nettoiera automatiquement tous les fichiers
    générés. Vous pouvez aussi l'exécuter avec le paramètre
    dist, auquel cas elle se comporte comme
    make distclean, et supprime aussi les fichiers flex/bison.
   
    Par défaut, tous les fichiers sont écrits dans un sous-répertoire de
    debug ou release. Pour installer
    ces fichiers en utilisant les emplacements standards, et pour générer aussi
    les fichiers nécessaire à l'installation et l'utilisation de la base de données,
    exécutez la commande :
    
install c:\destination\directory
Si vous voulez seulement installer les applications clientes et les bibliothèques, vous pouvez utiliser ces commandes :
install c:\destination\directory client
    Pour exécuter les tests de régression, assurez-vous que vous avez terminé
    la construction de toutes les parties requises. Ensuite, assurez-vous que
    les DLL nécessaires au chargement de toutes les parties du système (comme
    les DLL Perl et Python pour les langages de procédure) sont présentes dans
    le chemin système. Dans le cas contraire, configurez-les dans le fichier
    buildenv.pl. Pour lancer les tests, exécutez une des
    commandes suivantes à partir du répertoire
    src\tools\msvc :
    
     vcregress check
     vcregress installcheck
     vcregress plcheck
     vcregress contribcheck
     vcregress modulescheck
     vcregress ecpgcheck
     vcregress isolationcheck
     vcregress bincheck
     vcregress recoverycheck
     vcregress taptest
    Pour modifier la planification utilisée (en parallèle par défaut), ajoutez-la à la ligne de commande, comme :
vcregress check serial
    vcregress taptest peut être utilisé pour exécuter les
    tests TAP d'un répertoire cible comme :
    
vcregress taptest src\bin\initdb\Pour plus d'informations sur les tests de régression, voir Chapitre 33.
    Les tests de régression des programmes clients, avec
    vcregress bincheck, sur les tests de restauration,
    avec vcregress recoverycheck ou sur les tests TAP
    avec vcregress taptest,
    nécessitent l'installation d'un module Perl supplémentaire :
    
        Au moment où ces lignes sont écrites, IPC::Run
        n'est pas inclus dans l'installation de ActiveState Perl,
        ni dans la bibliothèque ActiveState Perl Package Manager (PPM). Pour
        l'installer, téléchargez l'archive source
        IPC-Run-<version>.tar.gz à partir du
        CPAN, et
        décompressez-la. Modifiez le fichier buildenv.pl en
        ajoutant une variable PERL5LIB pointant vers le sous-répertoire
        lib des fichiers extraits de l'archive. Par
        exemple :
$ENV{PERL5LIB}=$ENV{PERL5LIB} . ';c:\IPC-Run-0.94\lib';
   Les tests TAP lancés par vcregress) supportent les
   variables d'environnement PROVE_TESTS, étendues
   automatiquement selon le modèle donné, et PROVE_FLAGS.
   Elles peuvent être mises en place dans un terminal Windows,
   avant de lancer vcregress :
set PROVE_FLAGS=--timer --jobs 2 set PROVE_TESTS=t/020*.pl t/010*.pl
   Il est possible de placer ces paramètres dans
   buildenv.pl :
$ENV{PROVE_FLAGS}='--timer --jobs 2'
$ENV{PROVE_TESTS}='t/020*.pl t/010*.pl'
De plus, le comportement des tests TAP peut être contrôlé par un ensemble de variables d'environnement, voir Section 33.4.1.
   Certains des tests TAP dépendent d'un ensemble de commandes externes qui
   pourraient, en option, déclencher des tests de trigger en relation.  Chacune
   de ces variables peuvent être initialisées ou désinitialisées dans le fichier
   buildenv.pl :
   
GZIP_PROGRAM
      Chemin vers une commande gzip. La valeur par
      défaut est gzip, qui cherchera une commande de ce nom
      dans le PATH configuré.
     
LZ4
      Chemin vers une commande lz4. La valeur par
      défaut est lz4, qui cherchera une commande de ce nom
      dans le PATH configuré.
     
OPENSSL
      Chemin vers une commande openssl. La valeur
      par défaut est openssl, qui recherchera une commande
      de ce nom dans le PATH configuré.
     
TAR
      Chemin vers une commande tar. La valeur par
      défaut est tar, qui cherchera une commande de ce nom
      dans le PATH configuré.
     
ZSTD
      Chemin vers une commande zstd. La valeur par
      défaut est zstd, qui cherchera une commande de ce nom
      dans PATH configuré.