Skip to content
Snippets Groups Projects
installation.sgml 106 KiB
Newer Older
<!-- doc/src/sgml/installation.sgml -->
<!--

Use </link> not just </> so INSTALL.html can be created without links
to the main documentation.  Don't use <xref>; or if you must, wrap it
in a standalone-ignore clause.

<chapter id="installation">
 <title><![%standalone-include[<productname>PostgreSQL</>]]>
  Installation from Source Code</title>

 <indexterm zone="installation">
  <primary>installation</primary>
 </indexterm>

 <para>
  This <![%standalone-include;[document]]>
  <![%standalone-ignore;[chapter]]> describes the installation of
  <productname>PostgreSQL</productname> using the source code
  distribution.  (If you are installing a pre-packaged distribution,
  such as an RPM or Debian package, ignore this
  <![%standalone-include;[document]]>
  <![%standalone-ignore;[chapter]]>
  and read the packager's instructions instead.)
 </para>

 <sect1 id="install-short">
  <title>Short Version</title>

  <para>
<synopsis>
./configure
adduser postgres
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data
su - postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data &gt;logfile 2&gt;&amp;1 &amp;
/usr/local/pgsql/bin/createdb test
/usr/local/pgsql/bin/psql test
</synopsis>
   The long version is the rest of this
   <![%standalone-include;[document.]]>
   <![%standalone-ignore;[chapter.]]>
  </para>
 </sect1>


 <sect1 id="install-requirements">
  <title>Requirements</title>

  <para>
   In general, a modern Unix-compatible platform should be able to run
   <productname>PostgreSQL</>.
   The platforms that had received specific testing at the
   time of release are listed in <xref linkend="supported-platforms">
   below. In the <filename>doc</> subdirectory of the distribution
   there are several platform-specific <acronym>FAQ</> documents you
   might wish to consult if you are having trouble.
  </para>

  <para>
   The following software packages are required for building
   <productname>PostgreSQL</>:

   <itemizedlist>
    <listitem>
     <para>
      <indexterm>
       <primary>make</primary>
      </indexterm>

      <acronym>GNU</> <application>make</> version 3.80 or newer is required; other
      <application>make</> programs or older <acronym>GNU</> <application>make</> versions will <emphasis>not</> work.
      (<acronym>GNU</> <application>make</> is sometimes installed under
      the name <filename>gmake</filename>.)  To test for <acronym>GNU</acronym>
      <application>make</application> enter:
<userinput>make --version</userinput>
</screen>
     </para>
    </listitem>

    <listitem>
     <para>
      You need an <acronym>ISO</>/<acronym>ANSI</> C compiler (at least
      versions of <productname>GCC</> are recommended, but
      <productname>PostgreSQL</> is known to build using a wide variety
      of compilers from different vendors.
     </para>
    </listitem>

    <listitem>
     <para>
      <application>tar</> is required to unpack the source
      distribution, in addition to either
      <application>gzip</> or <application>bzip2</>.
     </para>
    </listitem>

    <listitem>
     <para>
      <indexterm>
       <primary>readline</primary>
      </indexterm>
      <indexterm>
       <primary>libedit</primary>
      </indexterm>
      The <acronym>GNU</> <productname>Readline</> library is used by
      default.  It allows <application>psql</application> (the
      PostgreSQL command line SQL interpreter) to remember each
      command you type, and allows you to use arrow keys to recall and
      edit previous commands.  This is very helpful and is strongly
      recommended.  If you don't want to use it then you must specify
      the <option>--without-readline</option> option to
      <filename>configure</>. As an alternative, you can often use the
      BSD-licensed <filename>libedit</filename> library, originally
      developed on <productname>NetBSD</productname>. The
      <filename>libedit</filename> library is
      GNU <productname>Readline</productname>-compatible and is used if
      <filename>libreadline</filename> is not found, or if
      <option>--with-libedit-preferred</option> is used as an
      option to <filename>configure</>. If you are using a package-based
      Linux distribution, be aware that you need both the
      <literal>readline</> and <literal>readline-devel</> packages, if
      those are separate in your distribution.
    <listitem>
     <para>
      <indexterm>
       <primary>zlib</primary>
      </indexterm>

      The <productname>zlib</productname> compression library is
      used by default. If you don't want to use it then you must
      specify the <option>--without-zlib</option> option to
      <filename>configure</filename>. Using this option disables
      support for compressed archives in <application>pg_dump</> and
      <application>pg_restore</>.
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <para>
   The following packages are optional.  They are not required in the
   default configuration, but they are needed when certain build
   options are enabled, as explained below:

   <itemizedlist>
    <listitem>
     <para>
      To build the server programming language
      <application>PL/Perl</application> you need a full
      <productname>Perl</productname> installation, including the
      <filename>libperl</filename> library and the header files.
      Since <application>PL/Perl</application> will be a shared
      library, the <indexterm><primary>libperl</primary></indexterm>
      <filename>libperl</filename> library must be a shared library
      also on most platforms.  This appears to be the default in
      recent <productname>Perl</productname> versions, but it was not
      in earlier versions, and in any case it is the choice of whomever
      installed Perl at your site.
      If you intend to make more than incidental use of
      <application>PL/Perl</application>, you should ensure that the
      <productname>Perl</productname> installation was built with the
      <literal>usemultiplicity</> option enabled (<literal>perl -V</>
      will show whether this is the case).
     </para>

     <para>
      If you don't have the shared library but you need one, a message
      like this will appear during the <productname>PostgreSQL</>
      build to point out this fact:
<screen>
*** Cannot build PL/Perl because libperl is not a shared library.
*** You might have to rebuild your Perl installation.  Refer to
*** the documentation for details.
</screen>
      (If you don't follow the on-screen output you will merely notice
      that the <application>PL/Perl</application> library object,
      <filename>plperl.so</filename> or similar, will not be
      installed.)  If you see this, you will have to rebuild and
      install <productname>Perl</productname> manually to be able to
      build <application>PL/Perl</application>.  During the
      configuration process for <productname>Perl</productname>,
      request a shared library.
     </para>
    </listitem>

    <listitem>
     <para>
      To build the <application>PL/Python</> server programming
      language, you need a <productname>Python</productname>
      installation with the header files and
      the <application>distutils</application> module.  The minimum
      required version is <productname>Python</productname> 2.3.
      (To work with function arguments of type <type>numeric</>, a 2.3.x
      installation must include the separately-available <filename>cdecimal</>
      module; note the <application>PL/Python</> regression tests
      will not pass if that is missing.)
      <productname>Python 3</productname> is supported if it's
      version 3.1 or later; but see
      <![%standalone-include[the <application>PL/Python</> documentation]]>
      <![%standalone-ignore[<xref linkend="plpython-python23">]]>
      when using Python 3.
     </para>

     <para>
      Since <application>PL/Python</application> will be a shared
      library, the <indexterm><primary>libpython</primary></indexterm>
      <filename>libpython</filename> library must be a shared library
      also on most platforms.  This is not the case in a default
      <productname>Python</productname> installation.  If after
      building and installing <productname>PostgreSQL</> you have a file called
      <filename>plpython.so</filename> (possibly a different
      extension), then everything went well.  Otherwise you should
      have seen a notice like this flying by:
<screen>
*** Cannot build PL/Python because libpython is not a shared library.
*** You might have to rebuild your Python installation.  Refer to
*** the documentation for details.
</screen>
      That means you have to rebuild (part of) your
      <productname>Python</productname> installation to create this
      shared library.
     </para>

     <para>
      If you have problems, run <productname>Python</> 2.3 or later's
      configure using the <literal>--enable-shared</> flag.  On some
      operating systems you don't have to build a shared library, but
      you will have to convince the <productname>PostgreSQL</> build
      system of this.  Consult the <filename>Makefile</filename> in
      the <filename>src/pl/plpython</filename> directory for details.
     </para>
    </listitem>

    <listitem>
     <para>
      To build the <application>PL/Tcl</application>
      procedural language, you of course need a <productname>Tcl</>
      installation.  If you are using a pre-8.4 release of
      <productname>Tcl</>, ensure that it was built without multithreading
      support.
     </para>
    </listitem>

    <listitem>
     <para>
      To enable Native Language Support (<acronym>NLS</acronym>), that
      is, the ability to display a program's messages in a language
      other than English, you need an implementation of the
      <application>Gettext</> <acronym>API</acronym>.  Some operating
      systems have this built-in (e.g., <systemitem
      class="osname">Linux</>, <systemitem class="osname">NetBSD</>,
      <systemitem class="osname">Solaris</>), for other systems you
      can download an add-on package from <ulink
      url="http://www.gnu.org/software/gettext/"></ulink>.
      If you are using the <application>Gettext</> implementation in
      the <acronym>GNU</acronym> C library then you will additionally
      need the <productname>GNU Gettext</productname> package for some
      utility programs.  For any of the other implementations you will
      not need it.
     </para>
    </listitem>

    <listitem>
     <para>
      You need <application>Kerberos</>, <productname>OpenSSL</>,
      <productname>OpenLDAP</>, and/or
      <application>PAM</>, if you want to support authentication or
     </para>
    </listitem>
      To build the <productname>PostgreSQL</productname> documentation,
      there is a separate set of requirements; see
      <![%standalone-ignore;[<xref linkend="docguide-toolsets">.]]>
      <![%standalone-include;[the main documentation's appendix on
      documentation.]]>
   </itemizedlist>
  </para>

  <para>
   If you are building from a <productname>Git</productname> tree instead of
   using a released source package, or if you want to do server development,
   you also need the following packages:

   <itemizedlist>
    <listitem>
     <para>
      <indexterm>
       <primary>flex</primary>
      </indexterm>
      <indexterm>
       <primary>bison</primary>
      </indexterm>
      <indexterm>
       <primary>yacc</primary>
      </indexterm>

      GNU <application>Flex</> and <application>Bison</>
      are needed to build from a Git checkout, or if you changed the actual
      scanner and parser definition files. If you need them, be sure
      to get <application>Flex</> 2.5.31 or later and
      <application>Bison</> 1.875 or later. Other <application>lex</>
      and <application>yacc</> programs cannot be used.
     </para>
    </listitem>
    <listitem>
     <para>
      <indexterm>
       <primary>perl</primary>
      </indexterm>

      <application>Perl</> 5.8 or later is needed to build from a Git checkout,
      or if you changed the input files for any of the build steps that
      use Perl scripts.  If building on Windows you will need
      <application>Perl</> in any case.  <application>Perl</application> is
      also required to run some test suites.
   </itemizedlist>
  </para>

  <para>
   If you need to get a <acronym>GNU</acronym> package, you can find
   it at your local <acronym>GNU</acronym> mirror site (see <ulink
   url="http://www.gnu.org/order/ftp.html"></>
   for a list) or at <ulink
   url="ftp://ftp.gnu.org/gnu/"></ulink>.
  </para>

  <para>
   Also check that you have sufficient disk space. You will need about
   100 MB for the source tree during compilation and about 20 MB for
   the installation directory. An empty database cluster takes about
   35 MB; databases take about five times the amount of space that a
   flat text file with the same data would take. If you are going to
   run the regression tests you will temporarily need up to an extra
   150 MB. Use the <command>df</command> command to check free disk
   space.
  </para>
 </sect1>

<![%standalone-ignore;[
 <sect1 id="install-getsource">
  <title>Getting The Source</title>

  <para>
   The <productname>PostgreSQL</> &version; sources can be obtained from the
   download section of our
   website: <ulink url="http://www.postgresql.org/download/"></ulink>.  You
   should get a file named <filename>postgresql-&version;.tar.gz</filename>
   or <filename>postgresql-&version;.tar.bz2</filename>. After
   you have obtained the file, unpack it:
<screen>
<userinput>gunzip postgresql-&version;.tar.gz</userinput>
<userinput>tar xf postgresql-&version;.tar</userinput>
</screen>
   (Use <command>bunzip2</command> instead of <command>gunzip</command> if you
   have the <filename>.bz2</filename> file.)
   This will create a directory
   <filename>postgresql-&version;</filename> under the current directory
   with the <productname>PostgreSQL</> sources.
   Change into that directory for the rest
   of the installation procedure.
  </para>

  <para>
   You can also get the source directly from the version control repository, see
 </sect1>
]]>

 <sect1 id="install-procedure">
  <title>Installation Procedure</title>

  <procedure>

  <step id="configure">

   <indexterm zone="configure">
    <primary>configure</primary>
   </indexterm>

   <para>
    The first step of the installation procedure is to configure the
    source tree for your system and choose the options you would like.
    This is done by running the <filename>configure</> script. For a
    default installation simply enter:
<screen>
<userinput>./configure</userinput>
</screen>
    This script will run a number of tests to determine values for various
    system dependent variables and detect any quirks of your
    operating system, and finally will create several files in the
    build tree to record what it found.  You can also run
    <filename>configure</filename> in a directory outside the source
    tree, if you want to keep the build directory separate.  This
    procedure is also called a
    <indexterm><primary>VPATH</primary></indexterm><firstterm>VPATH</firstterm>
    build.  Here's how:
<screen>
<userinput>mkdir build_dir</userinput>
<userinput>cd build_dir</userinput>
<userinput>/path/to/source/tree/configure [options go here]</userinput>
<userinput>make</userinput>
</screen>
   </para>

   <para>
    The default configuration will build the server and utilities, as
    well as all client applications and interfaces that require only a
    C compiler. All files will be installed under
    <filename>/usr/local/pgsql</> by default.
   </para>

   <para>
    You can customize the build and installation process by supplying one
    or more of the following command line options to
    <filename>configure</filename>:

     <variablelist>
      <varlistentry>
       <term><option>--prefix=<replaceable>PREFIX</></option></term>
       <listitem>
        <para>
         Install all files under the directory <replaceable>PREFIX</>
         instead of <filename>/usr/local/pgsql</filename>. The actual
         files will be installed into various subdirectories; no files
         will ever be installed directly into the
         <replaceable>PREFIX</> directory.
        </para>

        <para>
         If you have special needs, you can also customize the
         individual subdirectories with the following options. However,
         if you leave these with their defaults, the installation will be
         relocatable, meaning you can move the directory after
         installation. (The <literal>man</> and <literal>doc</>
         locations are not affected by this.)
        </para>

        <para>
         For relocatable installs, you might want to use
         <filename>configure</filename>'s <literal>--disable-rpath</>
         option.  Also, you will need to tell the operating system how
         to find the shared libraries.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--exec-prefix=<replaceable>EXEC-PREFIX</></option></term>
       <listitem>
        <para>
         You can install architecture-dependent files under a
         different prefix, <replaceable>EXEC-PREFIX</>, than what
         <replaceable>PREFIX</> was set to. This can be useful to
         share architecture-independent files between hosts. If you
         omit this, then <replaceable>EXEC-PREFIX</> is set equal to
         <replaceable>PREFIX</> and both architecture-dependent and
         independent files will be installed under the same tree,
         which is probably what you want.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--bindir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Specifies the directory for executable programs. The default
         is <filename><replaceable>EXEC-PREFIX</>/bin</>, which
         normally means <filename>/usr/local/pgsql/bin</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--sysconfdir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Sets the directory for various configuration files,
         <filename><replaceable>PREFIX</>/etc</> by default.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--libdir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Sets the location to install libraries and dynamically loadable
         modules. The default is
         <filename><replaceable>EXEC-PREFIX</>/lib</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--includedir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Sets the directory for installing C and C++ header files. The
         default is <filename><replaceable>PREFIX</>/include</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--datarootdir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Sets the root directory for various types of read-only data
         files.  This only sets the default for some of the following
         options.  The default is
         <filename><replaceable>PREFIX</>/share</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--datadir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Sets the directory for read-only data files used by the
         installed programs. The default is
         <filename><replaceable>DATAROOTDIR</></>. Note that this has
         nothing to do with where your database files will be placed.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--localedir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Sets the directory for installing locale data, in particular
         message translation catalog files.  The default is
         <filename><replaceable>DATAROOTDIR</>/locale</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--mandir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         The man pages that come with <productname>PostgreSQL</> will be installed under
         this directory, in their respective
         <filename>man<replaceable>x</></> subdirectories.
         The default is <filename><replaceable>DATAROOTDIR</>/man</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--docdir=<replaceable>DIRECTORY</></option></term>
       <listitem>
        <para>
         Sets the root directory for installing documentation files,
         except <quote>man</> pages.  This only sets the default for
         the following options.  The default value for this option is
         <filename><replaceable>DATAROOTDIR</>/doc/postgresql</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--htmldir=<replaceable>DIRECTORY</></option></term>
         The HTML-formatted documentation for
         <productname>PostgreSQL</productname> will be installed under
         this directory.  The default is
         <filename><replaceable>DATAROOTDIR</></>.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>

     <note>
      <para>
       Care has been taken to make it possible to install
       <productname>PostgreSQL</> into shared installation locations
       (such as <filename>/usr/local/include</filename>) without
       interfering with the namespace of the rest of the system. First,
       the string <quote><literal>/postgresql</literal></quote> is
       automatically appended to <varname>datadir</varname>,
       <varname>sysconfdir</varname>, and <varname>docdir</varname>,
       unless the fully expanded directory name already contains the
       string <quote><literal>postgres</></quote> or
       <quote><literal>pgsql</></quote>. For example, if you choose
       <filename>/usr/local</filename> as prefix, the documentation will
       be installed in <filename>/usr/local/doc/postgresql</filename>,
       but if the prefix is <filename>/opt/postgres</filename>, then it
       will be in <filename>/opt/postgres/doc</filename>. The public C
       header files of the client interfaces are installed into
       <varname>includedir</varname> and are namespace-clean. The
       internal header files and the server header files are installed
       into private directories under <varname>includedir</varname>. See
       the documentation of each interface for information about how to
       access its header files. Finally, a private subdirectory will
       also be created, if appropriate, under <varname>libdir</varname>
       for dynamically loadable modules.
      </para>
     </note>
    </para>

    <para>
     <variablelist>
      <varlistentry>
       <term><option>--with-extra-version=<replaceable>STRING</></option></term>
       <listitem>
        <para>
         Append <replaceable>STRING</> to the PostgreSQL version number.  You
         can use this, for example, to mark binaries built from unreleased Git
         snapshots or containing custom patches with an extra version string
         such as a <command>git describe</command> identifier or a
         distribution package release number.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-includes=<replaceable>DIRECTORIES</></option></term>
       <listitem>
        <para>
         <replaceable>DIRECTORIES</> is a colon-separated list of
         directories that will be added to the list the compiler
         searches for header files. If you have optional packages
         (such as GNU <application>Readline</>) installed in a non-standard
         location,
         you have to use this option and probably also the corresponding
         <option>--with-libraries</> option.
        </para>
        <para>
         Example: <literal>--with-includes=/opt/gnu/include:/usr/sup/include</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-libraries=<replaceable>DIRECTORIES</></option></term>
       <listitem>
        <para>
         <replaceable>DIRECTORIES</> is a colon-separated list of
         directories to search for libraries. You will probably have
         to use this option (and the corresponding
         <option>--with-includes</> option) if you have packages
         installed in non-standard locations.
        </para>
        <para>
         Example: <literal>--with-libraries=/opt/gnu/lib:/usr/sup/lib</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--enable-nls<optional>=<replaceable>LANGUAGES</replaceable></optional></option></term>
       <listitem>
        <para>
         Enables Native Language Support (<acronym>NLS</acronym>),
         that is, the ability to display a program's messages in a
         language other than English.
         <replaceable>LANGUAGES</replaceable> is an optional space-separated
         list of codes of the languages that you want supported, for
         example <literal>--enable-nls='de fr'</>.  (The intersection
         between your list and the set of actually provided
         translations will be computed automatically.)  If you do not
         specify a list, then all available translations are
         installed.
        </para>

        <para>
         To use this option, you will need an implementation of the
         <application>Gettext</> API; see above.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-pgport=<replaceable>NUMBER</></option></term>
       <listitem>
        <para>
         Set <replaceable>NUMBER</> as the default port number for
         server and clients. The default is 5432. The port can always
         be changed later on, but if you specify it here then both
         server and clients will have the same default compiled in,
         which can be very convenient.  Usually the only good reason
         to select a non-default value is if you intend to run multiple
         <productname>PostgreSQL</> servers on the same machine.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-perl</option></term>
       <listitem>
        <para>
         Build the <application>PL/Perl</> server-side language.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-python</option></term>
       <listitem>
        <para>
         Build the <application>PL/Python</> server-side language.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-tcl</option></term>
       <listitem>
        <para>
         Build the <application>PL/Tcl</> server-side language.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-tclconfig=<replaceable>DIRECTORY</replaceable></option></term>
       <listitem>
        <para>
         Tcl installs the file <filename>tclConfig.sh</filename>, which
         contains configuration information needed to build modules
         interfacing to Tcl. This file is normally found automatically
         at a well-known location, but if you want to use a different
         version of Tcl you can specify the directory in which to look
         for it.
        </para>
       </listitem>
      </varlistentry>

Magnus Hagander's avatar
Magnus Hagander committed
      <varlistentry>
       <term><option>--with-gssapi</option></term>
       <listitem>
        <para>
         Build with support for GSSAPI authentication. On many
         systems, the GSSAPI (usually a part of the Kerberos installation)
         system is not installed in a location
         that is searched by default (e.g., <filename>/usr/include</>,
         <filename>/usr/lib</>), so you must use the options
         <option>--with-includes</> and <option>--with-libraries</> in
         addition to this option.  <filename>configure</> will check
         for the required header files and libraries to make sure that
         your GSSAPI installation is sufficient before proceeding.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-krb-srvnam=<replaceable>NAME</></option></term>
       <listitem>
        <para>
         The default name of the Kerberos service principal used
         by GSSAPI.
Bruce Momjian's avatar
 
Bruce Momjian committed
         <literal>postgres</literal> is the default. There's usually no
Magnus Hagander's avatar
Magnus Hagander committed
         reason to change this unless you have a Windows environment,
         in which case it must be set to upper case
Magnus Hagander's avatar
Magnus Hagander committed
         <literal>POSTGRES</literal>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-openssl</option>
       <indexterm>
        <primary>OpenSSL</primary>
        <seealso>SSL</seealso>
       </indexterm>
       <listitem>
        <para>
         Build with support for <acronym>SSL</> (encrypted)
         connections. This requires the <productname>OpenSSL</>
         package to be installed.  <filename>configure</> will check
         for the required header files and libraries to make sure that
         your <productname>OpenSSL</> installation is sufficient
         before proceeding.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-pam</option></term>
       <listitem>
        <para>
         Build with <acronym>PAM</><indexterm><primary>PAM</></>
         (Pluggable Authentication Modules) support.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-ldap</option></term>
       <listitem>
        <para>
         Build with <acronym>LDAP</><indexterm><primary>LDAP</></>
         support for authentication and connection parameter lookup (see
         <![%standalone-include[the documentation about client authentication
         and libpq]]><![%standalone-ignore[<xref linkend="libpq-ldap"> and
         <xref linkend="auth-ldap">]]> for more information). On Unix,
         this requires the <productname>OpenLDAP</> package to be
         installed. On Windows, the default <productname>WinLDAP</>
         library is used.  <filename>configure</> will check for the required
         header files and libraries to make sure that your
         <productname>OpenLDAP</> installation is sufficient before
        </para>
       </listitem>
      </varlistentry>

       <term><option>--without-readline</option></term>
         Prevents use of the <application>Readline</> library
         (and <application>libedit</> as well).  This option disables
         command-line editing and history in
         <application>psql</application>, so it is not recommended.
      <varlistentry>
       <term><option>--with-libedit-preferred</option></term>
         Favors the use of the BSD-licensed <application>libedit</> library
         rather than GPL-licensed <application>Readline</>.  This option
         is significant only if you have both libraries installed; the
         default in that case is to use <application>Readline</>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-bonjour</option></term>
         Build with Bonjour support.  This requires Bonjour support
         in your operating system.  Recommended on OS X.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-uuid=<replaceable>LIBRARY</replaceable></option></term>
       <listitem>
        <para>
         Build the <![%standalone-include[uuid-ossp]]>
         <![%standalone-ignore[<xref linkend="uuid-ossp">]]> module
         (which provides functions to generate UUIDs), using the specified
         UUID library.<indexterm><primary>UUID</primary></indexterm>
         <replaceable>LIBRARY</replaceable> must be one of:
        </para>
        <itemizedlist>
         <listitem>
          <para>
           <option>bsd</> to use the UUID functions found in FreeBSD, NetBSD,
           and some other BSD-derived systems
          </para>
         </listitem>
         <listitem>
          <para>
           <option>e2fs</> to use the UUID library created by
           the <literal>e2fsprogs</> project; this library is present in most
           Linux systems and in OS X, and can be obtained for other
           platforms as well
          </para>
         </listitem>
         <listitem>
          <para>
           <option>ossp</> to use the <ulink
           url="http://www.ossp.org/pkg/lib/uuid/">OSSP UUID library</ulink>
          </para>
         </listitem>
        </itemizedlist>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--with-ossp-uuid</option></term>
       <listitem>
        <para>
         Obsolete equivalent of <literal>--with-uuid=ossp</literal>.
      <varlistentry>
       <term><option>--with-libxml</option></term>
       <listitem>
        <para>
         Build with libxml (enables SQL/XML support).  Libxml version 2.6.23 or
         later is required for this feature.

        <para>
         Libxml installs a program <command>xml2-config</command> that
         can be used to detect the required compiler and linker
         options.  PostgreSQL will use it automatically if found.  To
         specify a libxml installation at an unusual location, you can
         either set the environment variable
         <envar>XML2_CONFIG</envar> to point to the
         <command>xml2-config</command> program belonging to the
         installation, or use the options
         <option>--with-includes</option> and
         <option>--with-libraries</option>.
Tom Lane's avatar
Tom Lane committed
        </para>
      <varlistentry>
       <term><option>--with-libxslt</option></term>
       <listitem>
        <para>
         Use libxslt when building the
         <![%standalone-include[xml2]]>
         <![%standalone-ignore[<xref linkend="xml2">]]>
         module.  <application>xml2</> relies on this library
         to perform XSL transformations of XML.
        </para>
       </listitem>
      </varlistentry>

       <term><option>--disable-integer-datetimes</option></term>
         Disable support for 64-bit integer storage for timestamps and
         intervals, and store datetime values as floating-point
         numbers instead. Floating-point datetime storage was the
         default in <productname>PostgreSQL</productname> releases
         prior to 8.4, but it is now deprecated, because it does not
         support microsecond precision for the full range of
         <type>timestamp</type> values. However, integer-based
         datetime storage requires a 64-bit integer type. Therefore,
         this option can be used when no such type is available, or
         for compatibility with applications written for prior
         versions of <productname>PostgreSQL</productname>. See
         <![%standalone-include[the documentation about datetime datatypes]]>
         <![%standalone-ignore[<xref linkend="datatype-datetime">]]>
      <varlistentry>
       <term><option>--disable-float4-byval</option></term>
       <listitem>
        <para>
         Disable passing float4 values <quote>by value</>, causing them
         to be passed <quote>by reference</> instead.  This option costs
         performance, but may be needed for compatibility with old
         user-defined functions that are written in C and use the
         <quote>version 0</> calling convention.  A better long-term
         solution is to update any such functions to use the
         <quote>version 1</> calling convention.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><option>--disable-float8-byval</option></term>
       <listitem>
        <para>
         Disable passing float8 values <quote>by value</>, causing them
         to be passed <quote>by reference</> instead.  This option costs
         performance, but may be needed for compatibility with old
         user-defined functions that are written in C and use the
         <quote>version 0</> calling convention.  A better long-term
         solution is to update any such functions to use the
         <quote>version 1</> calling convention.
         Note that this option affects not only float8, but also int8 and some