構成（Configuration）
インストール手順の最初のステップは、システムに合わせてソースツリーを設定し、使用するオプションを選択することです。 configureスクリプトを実行することでこれを行います。 デフォルトのインストールを行う場合は、単に以下を入力してください。
./configure
このスクリプトは、各種のシステムに依存した変数の値を推定するために多くの試験を行い、使用中のオペレーティングシステムが持つクセを検出し、最終的に構築用ツリーに結果を記録するためのファイルをいくつか作成します （構築用のディレクトリを別の場所にしたい場合は、ソースツリーの外のディレクトリでconfigureを実行することもできます）。
デフォルトの構成では、サーバ、ユーティリティの他に、Cコンパイラだけを必要とするクライアントアプリケーションやインタフェースを構築します。 デフォルトでは、全てのファイルは/usr/local/pgsql以下にインストールされます。
configureに以下のコマンドラインオプションを1つ以上指定することで、構築処理やインストール処理を変更することができます。
--prefix=PREFIX/usr/local/pgsqlではなく、PREFIXディレクトリ以下に全てのファイルをインストールします。 ファイルは実際には様々なサブディレクトリにインストールされ、PREFIXディレクトリの直下にインストールされるファイルはありません。
特別な必要性があるのであれば、以下のオプションを使用して個々のサブディレクトリを変更することもできます。 しかし、これらをそのまま使用した場合、インストレーションは位置再変更可能になります。 つまり、インストールの後にディレクトリを移動することができます （manとdocの場所はこの影響を受けません）。
インストールの位置再変更のために、configureの--disable-rpathを使用しようと考えるかもしれません。 その場合は、オペレーティングシステムにその共有ライブラリの場所を通知する必要があるでしょう。
--exec-prefix=EXEC-PREFIXアーキテクチャ依存のファイルをPREFIXの設定とは別の接頭辞EXEC-PREFIX以下にインストールすることができます。 ホスト間でアーキテクチャ非依存のファイルを共有する場合に便利です。 省略した場合、EXEC-PREFIXはPREFIXと同じに設定され、アーキテクチャに依存するファイルも非依存なファイルも同じツリー以下にインストールされます。 ほとんどの場合、これが望まれています。
--bindir=DIRECTORY実行可能プログラム用のディレクトリを指定します。 デフォルトではEXEC-PREFIX/binであり、通常/usr/local/pgsql/binとなります。
--datadir=DIRECTORYインストールされたプログラムで使用される、読み取り専用データファイルのディレクトリを指定します。 デフォルトはPREFIX/shareです。 これはデータベースファイルを格納する場所とはまったく関係がないことに注意してください。
--sysconfdir=DIRECTORY各種設定ファイル用のディレクトリです。 デフォルトではPREFIX/etcです。
--libdir=DIRECTORYライブラリや動的ロード可能モジュールをインストールする場所です。 デフォルトはEXEC-PREFIX/libです。
--includedir=DIRECTORYCおよびC++のヘッダファイルをインストールするディレクトリです。 デフォルトはPREFIX/includeです。
--mandir=DIRECTORYPostgreSQL付属のマニュアルページがこのディレクトリ以下の、対応するmanxサブディレクトリにインストールされます。 デフォルトはPREFIX/manです。
--with-docdir=DIRECTORY--without-docdir"man"ページ以外の文書ファイルがこのディレクトリにインストールされます。
デフォルトはPREFIX/docです。
--without-docdirオプションが指定された場合、文書はmake installによってインストールされません。
これは、文書のインストール用に特別な方法を持つパッケージ作成スクリプトを目的としています。
注意: （/usr/local/includeといった）共用のインストール場所に、システムの他の名前空間に影響を与えることなくPostgreSQLをインストールすることができるような配慮がなされています。 まず、完全に展開したディレクトリ名に"postgres"か"pgsql"という文字列が含まれていない場合、"/postgresql"という文字列が自動的に
datadir、sysconfdir、docdirに追加されます。 例えば、接頭辞として/usr/localを使用する場合、文書は/usr/local/doc/postgresqlにインストールされますが、接頭辞が/opt/postgresの場合は/opt/postgres/docにインストールされます。 クライアントインタフェース用の外部向けCヘッダファイルはincludedirにインストールされ、名前空間の問題はありません。 内部向けヘッダファイルやサーバ用ヘッダファイルは、includedir以下の非公開ディレクトリにインストールされます。 各インタフェース用のヘッダファイルを取り出す方法についての情報は、そのインタフェースの文書を参照してください。 最後に、適切であれば、動的ロード可能モジュール用にlibdir以下にも非公開用のサブディレクトリが作成されます。
--with-includes=DIRECTORIESDIRECTORIESには、コンパイラがヘッダファイルを検索するディレクトリのリストをコロンで区切って指定します。
（GNU Readlineなどの）オプションのパッケージが非標準的な場所にインストールされている場合、このオプションと、おそらく対応する--with-librariesオプションを使用する必要があります。
例： --with-includes=/opt/gnu/include:/usr/sup/include
--with-libraries=DIRECTORIESDIRECTORIESには、ライブラリを検索するディレクトリのリストをコロンで区切って指定します。
パッケージが非標準的な場所にインストールされている場合は、おそらくこのオプション（と対応する--with-includesオプション）を使用する必要があります。
例： --with-libraries=/opt/gnu/lib:/usr/sup/lib
--enable-nls[=LANGUAGES]各国語サポート（NLS）、つまり、英語以外の言語によるプログラムメッセージの表示機能を有効にします。 LANGUAGESにはサポート予定言語のコードのリストを空白で区切って指定します。 例えば、--enable-nls='de fr'などとします （指定したリストと実際に用意された翻訳との論理積が自動的に計算されます）。 リストに何も指定しなかった場合、利用可能な翻訳全てがインストールされます。
このオプションを使用するためには、gettext APIの実装が必要です。 上記を参照してください。
--with-pgport=NUMBERサーバとクライアントのデフォルトのポート番号をNUMBERに設定します。 デフォルトは5432です。 このポートは後でいつでも変更することができますが、ここで指定した場合、サーバとクライアントはコンパイル時に同じデフォルト値を持つようになります。 これは非常に便利です。 通常、デフォルト以外の値を選択すべき唯一の理由は、同じマシンで複数のPostgreSQLを稼働させることです。
--with-perlPL/Perlサーバサイド言語を構築します。
--with-pythonPL/Pythonサーバサイド言語を構築します。
--with-tclPL/Tclサーバサイド言語を構築します。
--with-tclconfig=DIRECTORYTclは、Tclへのインタフェースモジュールを構築するために必要な設定情報を含むファイルtclConfig.shをインストールします。 このファイルは通常、自動的に一般的に知られている場所にインストールされますが、もしTclの別のバージョンを使いたい場合は、インストールしたいディレクトリを指定できます。
--with-krb5Kerberos 5 認証のサポートを構築します。
多くのシステムでは、Kerberosシステムはデフォルトの検索場所（例えば/usr/includeや/usr/lib）にインストールされていません。
そのため、--with-includesと--with-librariesオプションをさらに追加して使わなければいけません。
configureは、処理を進める前にKerberosが正しくインストールされていることを確認するために、必要とされるヘッダファイルとライブラリを検査します。
--with-krb-srvnam=NAMEKerberos のサービスプリンシパルのデフォルトの名前です。 デフォルトでは"postgres"です。 これを変える理由は特にありません。
--with-opensslSSL（暗号化）接続のサポートを有効にして構築します。 これには、OpenSSLパッケージがインストールされていなければなりません。 configureは、処理を進める前にOpenSSLのインストールを確認するために、必要なヘッダファイルとライブラリを検査します。
--with-pam--without-readlineReadlineライブラリの使用を防止します。 これによりpsqlでのコマンドライン編集および履歴が無効となるため、推奨されません。
--with-bonjourBonjourサポートを有効にして構築します。 これにはオペレーティングシステムがBonjourをサポートしていることが必要です。 Mac OS Xでは推奨します。
--enable-integer-datetimes日付時刻および時間間隔で、デフォルトの浮動小数点格納方式ではなく64ビット整数格納方式を使用します。 これにより表現できる値の範囲が狭まりますが、範囲全体に対してミリ秒単位の精度を保証できます。 （詳細は 項8.5）を参照してください。 また、この整数による日付時刻のコードは浮動小数点用よりも新しく、バグをつぶしている段階であることに注意してください。
--disable-spinlocksPostgreSQLがそのプラットフォーム用のCPUスピンロックをサポートしない場合でも、構築に成功するようにします。 スピンロックのサポートの欠落により、性能は悪化します。 したがって、このオプションは、構築が失敗し、その原因が使用するプラットフォームでスピンロックサポートが欠落している場合にのみ使用してください。 使用するプラットフォームにおけるPostgreSQLの構築にこのオプションが必要とされた場合は、PostgreSQL開発者にその問題を報告してください。
--enable-thread-safetyクライアントライブラリをスレッドセーフで作成します。 これにより、libpqやECPGプログラム内の同時実行スレッドは、安全にその固有の接続ハンドルを制御することができます。 このオプションは、オペレーティングシステムで適切なスレッド処理がサポートされていることが必要です。
--without-zlibZlibライブラリの使用を抑制します。 これは、pg_dumpとpg_restoreにおける圧縮アーカイブのサポートを無効にします。 このオプションは、このライブラリが利用できないごく少数のシステム向けだけのものです。
--enable-debug全てのプログラムとライブラリをデバッグシンボル付きでコンパイルします。 これは、問題を解析するためにデバッガを使用してプログラムを実行できることを意味します。 これはインストールする実行形式ファイルのサイズをかなり大きくし、また、GCC以外のコンパイラでは、通常はコンパイラによる最適化が行われなくなりますので、低速になります。 しかし、デバッグシンボルが利用できるということは、発生した問題に対応する時に非常に便利です。 現在のところ、GCC を使用している場合にのみ、稼働用のインストレーションにこのオプションを使用することを推奨します。 しかし、開発作業時やベータ版を実行する時は、常にこれを有効にすべきです。
--enable-cassertサーバにおける、多くの"あり得ない"状態をテストするアサーションチェックを有効にします。 これは、プログラムの開発のためには測り知れない価値がありますが、このテストにより多少低速になります。 また、このテストを有効にすると、サーバの安定性を向上させるとは限りません！ アサーションチェックは、重要度によって分類されていませんので、比較的害がないようなバグでも、アサーション失敗をトリガとした、サーバの再起動が行われてしまいます。 現在のところ、稼働用にこのオプションを使用することは推奨されませんが、開発作業時やベータ版を実行する場合は、これを有効にすべきです。
--enable-depend自動依存関係追跡を有効にします。 このオプションを使用すると、ヘッダファイルが変更された場合に、影響を受ける全てのオブジェクトファイルが再構築されるように、makefile が設定されます。 これは開発作業時には有用ですが、単に一度コンパイルしインストールするだけであれば、これは無駄なオーバーヘッドです。 現在のところ、GCC を使用している場合にのみ、このオプションは動作します。
configureが選ぶものと違うCコンパイラを使いたいという場合には、CC 環境変数をその使用したいプログラムに設定することができます。 デフォルトでは、configureは利用できるのであればgccを、利用できなければプラットフォームのデフォルト（通常cc）を選択します。 同様に、デフォルトのコンパイラフラグは必要に応じてCFLAGS変数で上書きすることもできます。
次のようにして、configureコマンドラインに環境変数を指定することができます。
./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
構築
構築作業を開始するには、以下を入力してください。
gmake
（GNU makeを使用することを忘れないでください。） ハードウェアに依存しますが、構築作業には5分から30分くらいかかります。 最後に以下のような行が表示されるはずです。
All of PostgreSQL is successfully made. Ready to install.
リグレッションテスト
インストールを行う前に、新しく構築したサーバをテストしたい場合、この時点でリグレッションテストを実行することができます。 リグレッションテストとは、使用するマシンにおいてPostgreSQLが、開発者の想定通りに動作することを検証するためのテストのまとまりです。 次のように入力します。
gmake check
（これは root では動作しません。 非特権ユーザとして実行してください。） 第27章にはテスト結果の表示に関する詳しい情報があります。 同じコマンドを入力することで、後にいつでもテストを繰り返すことができます。
ファイルのインストール
注意: もし既存のシステムのアップグレードをしていて、古いファイルの上から新しいファイルをインストールするという場合は、上記の項14.4で説明したように、確実にデータをバックアップして、処理を進める前に古いサーバをシャットダウンしてください。
PostgreSQLをインストールするには、以下を入力してください。
gmake install
これは、ファイルをステップ1で指定されたディレクトリにインストールします。 その領域に書き込むための権限を持っていることを確認してください。 通常はこのステップはrootで行う必要があります。 代わりに対象とするディレクトリを前もって作成し、適切に権限を調整することも可能です。
gmake installの代わりにgmake install-stripを使用することで、インストール時に実行可能ファイルやライブラリをストリップ（strip）することができます。 これにより、多少の容量を節約できます。 デバッグをサポートするように構築している場合、ストリップすることでデバッグのサポートも除去されます。 したがって、これはデバッグが必要なくなった場合にのみ実行すべきです。 install-stripは容量を節約するために適切な作業を行おうとしますが、実行可能ファイルから全ての不必要なバイトを完全にストリップすることはできません。 可能な限りのディスク容量を全て節約したい場合は、手動で作業を行う必要があります。
この標準的なインストール方法では、クライアントアプリケーションの開発に必要なヘッダファイルと、Cで独自の関数やデータ型を作成するといったサーバ側のプログラムの開発用のヘッダファイルが用意されます （PostgreSQL 8.0より前まででは、後で別途gmake install-all-headersコマンドが必要でした。しかし、この手順は標準のインストールに含まれるようになりました）。
クライアント側のみのインストール：. クライアントアプリケーションとインタフェースライブラリのみをインストールしたい場合、下記のコマンドを使います。
gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install
Windowsにおけるeventlogの登録：. Windows eventlogライブラリをオペレーティングシステムに登録するには、インストール後に以下のコマンドを実行してください。
regsvr32 pgsql_library_directory/pgevent.dll
これによりイベントビューアで使用されるレジストリ項目が生成されます。
アンインストール：. インストールを取り消すには、gmake uninstall コマンドを使います。しかし、作成済みのディレクトリは削除されません。
クリーニング：. インストールが終わったら、gmake clean コマンドを使ってソースツリーから構築用のファイルを削除し、ディスクの領域を空けることができます。 これはconfigureプログラムが作るファイルを保持するので、後でgmakeコマンドで全てを再構築できます。 ソースツリーを配布された時の状態に戻したい場合は、gmake distcleanコマンドを使います。 同じソースツリー内で複数のプラットフォーム向けに構築する場合、構築する度に、これを実行しconfigureをし直さなければいけません （または、未変更のソースツリーを維持するために、各プラットフォームで別々の構築用ツリーを使用してください）。
構築作業を行った後でconfigure用オプションが間違っていることに気付いた場合や、configureの調査結果に何らかの変更を加えた場合（例えば、ソフトウェアのアップグレードなど）、再設定と再構築の前にgmake distcleanを行うことをお勧めします。 さもないと、設定選択肢の変更は、必要なところ全てには反映されない可能性があります。