The full set of parameters available in configure can be obtained by typing $ ./configure --help The following parameters may be of interest to installers: Directories to install PostgreSQL in: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local/pgsql] --bindir=DIR user executables in DIR [EPREFIX/bin] --libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include] --mandir=DIR man documentation in DIR [PREFIX/man] Features and packages: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --enable and --with options recognized: --with-template=template use operating system template file see template directory --with-includes=dirs look for header files for tcl/tk, etc in DIRS --with-libraries=dirs look for additional libraries in DIRS --with-libs=dirs alternate spelling of --with-libraries --enable-locale enable locale support --enable-recode enable cyrillic recode support --enable-multibyte enable multibyte character support --with-pgport=portnum change default postmaster port --with-maxbackends=n set default maximum number of server processes --with-tcl build Tcl interfaces and pgtclsh --with-tclconfig=tcldir tclConfig.sh and tkConfig.sh are in DIR --with-perl build Perl interface and plperl --with-odbc build ODBC driver package --with-odbcinst=odbcdir change default directory for odbcinst.ini --enable-cassert enable assertion checks (for debugging) --enable-debug build with debugging symbols (-g) --with-CC=compiler use specific C compiler --with-CXX=compiler use specific C++ compiler --without-CXX prevent building C++ code Some systems may have trouble building a specific feature of Postgres. For example, systems with a damaged C++ compiler may need to specify --without-CXX to instruct the build procedure to skip construction of libpq++. Use the --with-includes and --with-libraries options if you want to build Postgres using include files or libraries that are not installed in your system's standard search path. For example, you might use these to build with an experimental version of Tcl. If you need to specify more than one nonstandard directory for include files or libraries, do it like this: --with-includes="/opt/tcl/include /opt/perl5/include" Many installation-related parameters can be set in the building stage of Postgres installation. In most cases, these parameters should be placed in a file, Makefile.custom, intended just for that purpose. The default distribution does not contain this optional file, so you will create it using a text editor of your choice. When upgrading installations, you can simply copy your old Makefile.custom to the new installation before doing the build. Alternatively, you can set variables on the make command line: make [ variable=value [...] ] A few of the many variables that can be specified are: POSTGRESDIR Top of the installation tree. BINDIR Location of applications and utilities. LIBDIR Location of object libraries, including shared libraries. HEADERDIR Location of include files. ODBCINST Location of installation-wide psqlODBC (ODBC) configuration file. There are other optional parameters which are not as commonly used. Many of those listed below are appropriate when doing Postgres server code development. CFLAGS Set flags for the C compiler. Should be assigned with "+=" to retain relevant default parameters. YFLAGS Set flags for the yacc/bison parser. -v might be used to help diagnose problems building a new parser. Should be assigned with "+=" to retain relevant default parameters. USE_TCL Enable Tcl interface building. HSTYLE DocBook HTML style sheets for building the documentation from scratch. Not used unless you are developing new documentation from the DocBook-compatible SGML source documents in doc/src/sgml/. PSTYLE DocBook style sheets for building printed documentation from scratch. Not used unless you are developing new documentation from the DocBook-compatible SGML source documents in doc/src/sgml/. Here is an example Makefile.custom for a PentiumPro Linux system: # Makefile.custom # Thomas Lockhart 1999-06-01 POSTGRESDIR= /opt/postgres/current CFLAGS+= -m486 -O2 # documentation HSTYLE= /home/tgl/SGML/db118.d/docbook/html PSTYLE= /home/tgl/SGML/db118.d/docbook/print Written by Oleg Bartunov. See Oleg's web page for additional information on locale and Russian language support. While doing a project for a company in Moscow, Russia, I encountered the problem that postgresql had no support of national alphabets. After looking for possible workarounds I decided to develop support of locale myself. I'm not a C-programer but already had some experience with locale programming when I work with perl (debugging) and glimpse. After several days of digging through the Postgres source tree I made very minor corections to src/backend/utils/adt/varlena.c and src/backend/main/main.c and got what I needed! I did support only for LC_CTYPE and LC_COLLATE, but later LC_MONETARY was added by others. I got many messages from people about this patch so I decided to send it to developers and (to my surprise) it was incorporated into the Postgres distribution. People often complain that locale doesn't work for them. There are several common mistakes: Didn't properly configure postgresql before compilation. You must run configure with --enable-locale option to enable locale support. Didn't setup environment correctly when starting postmaster. You must define environment variables LC_CTYPE and LC_COLLATE before running postmaster because backend gets information about locale from environment. I use following shell script (runpostgres): #!/bin/sh export LC_CTYPE=koi8-r export LC_COLLATE=koi8-r postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe' and run it from rc.local as /bin/su - postgres -c "/home/postgres/runpostgres" Broken locale support in OS (for example, locale support in libc under Linux several times has changed and this caused a lot of problems). Latest perl has also support of locale and if locale is broken perl -v will complain something like: 8:17[mira]:~/WWW/postgres>setenv LC_CTYPE not_exist 8:18[mira]:~/WWW/postgres>perl -v perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LC_CTYPE = "not_exist", LANG = (unset) are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Wrong location of locale files! Possible locations include: /usr/lib/locale (Linux, Solaris), /usr/share/locale (Linux), /usr/lib/nls/loc (DUX 4.0). Check man locale to find the correct location. Under Linux I did a symbolic link between /usr/lib/locale and /usr/share/locale to be sure that the next libc will not break my locale. You can use ~* and order by operators for strings contain characters from national alphabets. Non-english users definitely need that. If you won't use locale stuff just undefine the USE_LOCALE variable. There is one evident drawback of using locale - its speed! So, use locale only if you really need it. Kerberos is an industry-standard secure authentication system suitable for distributed computing over a public network. The Kerberos authentication system is not distributed with Postgres. Versions of Kerberos are typically available as optional software from operating system vendors. In addition, a source code distribution may be obtained through MIT Project Athena. You may wish to obtain the MIT version even if your vendor provides a version, since some vendor ports have been deliberately crippled or rendered non-interoperable with the MIT version. Users located outside the United States of America and Canada are warned that distribution of the actual encryption code in Kerberos is restricted by U. S. Government export regulations. Inquiries regarding your Kerberos should be directed to your vendor or MIT Project Athena. Note that FAQLs (Frequently-Asked Questions Lists) are periodically posted to the Kerberos mailing list (send mail to subscribe), and USENET news group. Installation of Kerberos itself is covered in detail in the Kerberos Installation Notes . Make sure that the server key file (the srvtab or keytab) is somehow readable by the Postgres account. Postgres and its clients can be compiled to use either Version 4 or Version 5 of the MIT Kerberos protocols by setting the KRBVERS variable in the file src/Makefile.global to the appropriate value. You can also change the location where Postgres expects to find the associated libraries, header files and its own server key file. After compilation is complete, Postgres must be registered as a Kerberos service. See the Kerberos Operations Notes and related manual pages for more details on registering services. After initial installation, Postgres should operate in all ways as a normal Kerberos service. For details on the use of authentication, see the PostgreSQL User's Guide reference sections for postmaster and psql. In the Kerberos Version 5 hooks, the following assumptions are made about user and service naming: User principal names (anames) are assumed to contain the actual Unix/Postgres user name in the first component. The Postgres service is assumed to be have two components, the service name and a hostname, canonicalized as in Version 4 (i.e., with all domain suffixes removed). Kerberos Parameter Example user frew@S2K.ORG user aoki/HOST=miyu.S2K.Berkeley.EDU@S2K.ORG host postgres_dbms/ucbvax@S2K.ORG Support for Version 4 will disappear sometime after the production release of Version 5 by MIT.