原文最終更新日: Thu May 18 23:52:32 EDT 2006
現在の維持管理者: Bruce Momjian (pgman at candle.pha.pa.us)
Maintainer of Japanese Translation: Jun Kuwamura (juk at PostgreSQL.jp)
この文書の最新版は http://www.postgresql.org/docs/faqs.FAQ.html で見ることができます。
プラットホームに特有の質問については:
http://www.postgresql.org/docs/faq/
に解答があります。
(以下、訳者による注釈を [訳注： と ] とで囲んで記します。)
[訳注：
日本語版のFAQは、
http://www.postgresql.org/docs/faqs.FAQ_japanese.html
にあります。
最新の日本語版については、この文書の最後にある「日本語版について」をごらんください。
]
PostgreSQLはPost-Gres-Q-L(ポスト・グレス・キュー・エル) と発音します。
また、ときによっては単純に Postgres として 参照されます。この発音を聞きたい人のために、 MP3フォー マットの音声ファイルがあります。PostgreSQL はオブジェクト-リレーショナルデータベースシステムで、 伝統的な商用データベースシステムに、次世代DBMSシステ ムに見られるような改良が施された特徴を有します。PostgreSQLは、無料で 完全なソースコードを手に入れることができます。
PostgreSQL の開発は、ほとんどが、世界中にひろがったボランティアの 開発者によって、インターネットを通したコミュニケーションによって行わ れています。コミュニティによるプロジェクトであるため、どの企業の制御 もうけません。開発に参加したければ、 http://www.postgresql.org/files/documentation/faqs/FAQ_DEV.html にある開発者のFAQを見てください。
PostgreSQLの門番、中央委員会、あるいは、コントロールをする会社を 探そうとしても、諦めざるをえず ---- 存在しないのです。我々は、中心 となるコミッティとCVSコミッタを持ちますが、これらのグループはコン トロールするためというよりも、管理上のものです。ここでは、プロジェ クトは、だれでも参加ができる開発者とユーザのコミュニティにより方向 付けられます。読者がやらなければならないことは、メーリングリストを サブスクライブして、議論に 参加することです。（Developer's FAQには、PostgreSQL開発に加わり方についての情報があります。）
PostgreSQL は下記の著作権に従います。
PostgreSQLは古くからのBSDライセンスの下で配布されています。それ は基本的には、利用者がそのコードを好き勝手に利用することが許されて います。制限があるとすれば、このソフトウェアに伴ういかなる問題にお いても法的に責任を我々に負わせることができないということです。 また、この著作権表示がこのソフトウェアのすべての複製に表示すること も必要です。以下に、我々が実際に使っているBSD使用許諾書を示します：
[訳注：
正文は英語です。参考として、訳文を併記掲載します。
]
PostgreSQL Data Base Management System
Portions Copyright (c) 1996-2006, PostgreSQL Global Development Group Portions Copyright (c) 1994-1996 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
POSTGRESQL データベース管理システム
部分的著作権 (c) 1996-2005, PostgreSQL国際開発チーム
部分的著作権 (c) 1994-1996 カリフォルニア大学本校
本ソフトウェアおよびその文書一式は上記の著作権表示と、この文章
およびこれに続く二つの段落が全ての複製に添付されている限りにおい
て、使用、複製、修正および配付の許可を、いかなる目的であっても、
無償でかつ同意書無しに行なえることをここに認めます。
カリフォルニア大学は、いかなる当事者にたいしても、利益の壊失を
含む、直接的、間接的、特別、偶然あるいは必然的にかかわらず生じた
損害について、たとえカリフォルニア大学がこれらの損害について訴追
を受けていたとしても、一切の責任を負いません。
カリフォルニア大学は、商用目的における暗黙の保証と、特定目的で
の適合性に関してはもとより、これらに限らず、いかなる保証も放棄す
ることを明言します。以下に用意されたソフトウェアは「そのまま」を
基本原理とし、カリフォルニア大学はそれを維持、支援、更新、改良あ
るいは修正する義務を負いません。
[訳注：
著作権に関する正文は上記の英語による表記です。日本語訳はあくまで
参考です。
]
一般的に、最近のUnix互換プラットホームであればPostgreSQLを稼働さ せられるはずです。リリースの時点で実際にテストを行なったことの報告が なされたプラットホームについてはインストール手引書に列挙してあります。
PostgreSQL は、Win2000, WinXP, そして、Win2003 のような Microsoft Windows NTベースのオペレーティングシステムで、ネイティブに走ります。 あらかじめパッケージにされたインストーラが http://pgfoundry.org/projects/pginstaller にあり、利用できます。MSDOSベースのWindowsのバージョン(Win95, Win98, WinMe)では、Cygwinを使って PostgreSQL を走らせることができます。
[訳注
pgInstaller の入手はFTPミラーサイトの win32 ディレクトリからも可能です。
http://www.postgresql.org/mirrors-ftp.html
詳しくは、次の Windows版に関するFAQの和訳をごらんください。
http://www.postgresql.jp/wg/jpugdoc/FAQ_windows.ja.html
]
次のサイトに Novell Netware 6 への移植版もあります。 http://forge.novell.com また、OS/2 (eComStation) バージョンは、 http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgreSQL&stype=all&sort=type&dir=%2Fにあります。
Webブラウザ経由だと、 http://www.postgresql.org/ftp/、それから、ftp経由だと、 ftp://ftp.PostgreSQL.org/pub/ を使います。
PostgreSQL の最新版はバージョン 8.1.4 です。
我々は、1年毎にメジャーリリースを、数ヵ月ごとのマイナーリリースを 行なうことを計画しています。
[訳注
バージョン番号の x.y.z の最初の x.y がメジャーリリースの番号に相
当し、最後の z がマイナーリリースの番号になります。メジャーリリー
スの番号が同じであれば、データベース・クラスタに互換性があります。
]
PostgreSQL コミュニティは多くのユーザのために、電子メール経由の支 援を提供しています。電子メールリストをサブスクライブするためのメイン となるウェブサイトは http://www.postgresql.org/community/lists/です。これから、始める のであれば general または、bugs といったリストがよいで しょう。
メジャーなIRC チャンネルは、Freenode (irc.freenode.net)の
#postgresql というチャンネルです。UNIX コマンドでは、
irc -c '#PostgreSQL' "$USER" irc.freenode.net を使って
参加できます。同じネットワークに、スペイン語のチャンネル
(#postgresql-es)もあり、フランス語のチャンネル
(#postgresqlfr)もあります。EFNetにもPostgreSQLチャンネルがあ
ります。
[訳注:
1999年7月23日、日本ポストグレスユーザー会、略称JPUGが設立されました。
JPUG は非営利組織で、PostgreSQLを利用する人達の相互協力の場となっています。
(2003年5月17日、「日本PostgreSQLユーザ会」に名称を改めました。)
正会員の会費は無料ですが、協賛会員の会費と会員の積極的な貢献が会の運営を助けています。
詳しくは、JPUG のWeb サイト:
http://www.PostgreSQL.jp/
をごらんください。会員登録も可能となっています。
日本語のIRCチャンネル '#PostgreSQL:*.jp' も存在します。
]
商用サポート会社のリストは http://techdocs.postgresql.org/companies.phpにあります。
http://www.postgresql.org/support/submitbug のPostgreSQL バグフォームを訪れてください。 バグレポートを提出する仕方 についての手引と指針があります。
それと同時に ftp サイト ftp://ftp.PostgreSQL.org/pub/ で、最新バージョンの PostgreSQL を探してみてください。
PostgreSQLは拡張されたSQL:2003のサブセットをサポート します。我々のページの TODO リストに、 既知のバグや欠落機能や将来計画についての記述があります。
特徴の要求は普通次のいずれかの解答の中にあります：
我々は、PostgreSQL に関して、電子メールで直接対応して TODO リストを最新に更新してゆくほうがより効果的であることを知っています ので、バグ追跡システムは使いません。 現実に、このソフトウェアの中でバグはそれほど長くはい続けませんし、 多くのユーザに影響するバグは早急に修正されます。PostgreSQLのリリース で、すべての変更点、改良点、そして、修正点を知りたければ、 CVS のログメッセージを見てください。リリースノートにさえ、このソフトウェア に加えられたすべての変更点は網羅されていません。
配付の中に、いくつかのマニュアルとオンライン・マニュアル(マニュ アル・ページ)およびいくつかの小さなテスト例題が含まれます。 /docディレクトリをごらんください。また、マニュアルは、 http://www.PostgreSQL.org/docs/でオンラインでも閲覧できます。
[訳注:
JPUG 文書・書籍関連分科会で翻訳されたマニュアルもあります。
http://www.postgresql.jp/document/pg803doc/
インプレスから、
PostgreSQLオフィシャルマニュアルとして出版されています。
]
オンラインで参照できる PostgreSQL の本も2冊あります。 http://www.PostgreSQL.org/docs/books/awbook.html
[訳注:
この本は、JPUG「PostgreSQL Book翻訳分科会」
で翻訳され、ピアソンから
「はじめてのPostgreSQL」として出版されています。
]
[訳注:
邦訳は「実践 PostgreSQL」
がオライリーから出版されています。
]
[訳注:
日本語の書籍等については、日本PostgreSQLユーザ会の、http://www.postgresql.jp/PostgreSQL/references.html
もごらんください。
]
コマンドラインのクライアントプログラムpsql も、型、演算子、 関数、集約、その他の情報をお見せする、いくつかの素晴らしい \d コマン ドを持ちます。 - \? を使うと利用可能なコマンドが表示されます。
我々の Web サイトには、さらに沢山の文書があります。
まず、 上記で述べた PostgreSQL についての本を読むことを検討してください。 もうひとつは、 "Teach Yourself SQL in 21 Days, Second Edition" at http://members.tripod.com/er4ebus/sql/index.htmです。
The Practical SQL Handbook, Bowman Judith S. et al., Addison-Wesley が多くのユーザに好評です。 ほかでは、The Complete Reference SQL, Groff et al., McGraw-Hill も好評です。
素晴らしい手引書は、
[訳注:
日本PostgreSQLユーザ会の日本語の参考文献の紹介ページ
http://www.postgresql.jp/PostgreSQL/references.html
があります。
近藤直文氏の「初心者向のＤＢ設計入門・ＳＱＬ入門参考書紹介」のコーナー
http://www.shonan.ne.jp/~nkon/ipsql/books_SQL.html
があります(やや古い2000年版)。
堀田倫英氏の「PostgreSQL日本語マニュアル」
http://www.net-newbie.com/
ではオンラインマニュアルの検索ができます。
丸山不二夫氏のUNIX データベース入門
http://www.wakhok.ac.jp/DB/DB.html
もオンラインで読むことができます。
Nikkei BP IT Pro にある石井達夫氏の PostgreSQL ウォッチ
では毎回新しい情報をとりあげています。
]
（開発者向けの）Developer's FAQをごらんください。
ソフトウェアを計る方法にはいくつかあります。機能と性能と信頼性と サポートと価格です。
PostgreSQL のインストールに含まれる物はCと組込み Cのインターフェースだけです。その他のインターフェース は独立したプロジェクトで、別々にダウンロードされます。分かれることで、 それぞれの開発チームが独自のリリーススケジュールを持つことが許されま す。
PHP のようないくつかのプログラミング言語は、 PostgreSQLのインターフェースを含んでいます。Perl, TCL, Python, そして、そのほかの利用可能な言語のインターフェースは、 http://gborg.postgresql.org の Drivers/Interfaces の節の中とインターネットの検索でみつけ られます。
データベースを裏に持つ Web ページについての素晴らしい紹介が、
http://www.webreview.comにあります。
Web への拡張のためには、PHP(http://www.php.net/) が卓越したインターフェースとなっています。
[訳注:
PHPに関する日本語の情報は、2000年4月19日に発足した日本PHPユーザ会のサイト
http://www.php.gr.jp/
あるいは、廣川 類さんのサイト
http://www.geocities.jp/rui_hirokawa/php/
にかなりまとめられています。
]
処理が複雑な場合、多くの人は Perl インターフェースと CGI.pm か mod_perl を使います。
もちろん、あります。 詳細は、http://techdocs.postgresql.org/guides/GUITools をごらんください。
簡単な方法は、 configure を走らせるときに --prefix オプショ ンを指定することです。
既定値では、PostgreSQL は Unix ドメインソケット、または、TCP/IP接 続のローカルマシンからの接続しか許しません。postgresql.conf の中の listen_addresses を修正し、かつ、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型認証を有効にしないかぎりは、他 のマシンからは接続できないでしょう。
性能改善の可能性のありそうな主な領域が3つあります：
[訳注:
JPUG理事長の片岡裕生氏による、「今すぐできるPostgreSQLチューニング」
というコーナーが ThinkIT サイトにあり、実作業の参考になります。
http://www.thinkit.co.jp/free/tech/10/1/1.html
]
サーバ構成変数には多くの log_* があり、クエリとプロ
セスの統計を出力することができ、デバグと性能計測にとても便利です。
既定での制限である 100 のデータベースセッションに達してしまって います。postmasterが同時接続できるバックエンドプロセスの制限 数を増やす必要があります。postgresql.conf の中の max_connections の値を変更して postmasterを再起動する ことで可能になります。
PostgreSQLチームはマイナーリリースでは小さな変更しか行ないません ので、7.4.0 から 7.4.1 へのアップグレードにはダンプとリストアの必要は ありません。しかし、メジャーリリース(たとえば、7.2から7.3へのような) では、システムテーブルやデータファイルの内部フォーマットの変更をしば しば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファ イルのための後方互換性を維持することができません。ダンプは汎用フォー マットでデータを出力し、それを新しい内部フォーマットに読み込むことが できます。
PCハードウェアはほとんど互換性がありますので、ほとんどの人は、す べてのPCハードウェアが同じ品質だと思い込む傾向があります。しかし、そ れは間違いです。ECC RAM、SCSI、および、高品質マザーボードは、安いハー ドウェアに比べると、より信頼性が高く、より性能も良いのです。 PostgreSQL はほとんどのハードウェアで稼働しますが、信頼性や性能が重 要な場合は、ハードウェアのオプションを研究することが賢明です。メーリ ングリストでもハードウェアオプションとトレードオフについて議論するこ とができます。
たったの数行のロウを取り出すために、何行必要かがわかれば、 SELECT のときに LIMIT を使います。 ORDER BYにインデックスがマッチした場合、まったくクエ リが実行されないこともあります。SELECT のときに何行 が必要かを知らなければ、カーソルを使いFETCHします。
ランダムロウをSELECTするには、次の文を使います：
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;
psql の中で \dtコマンドを使ってテーブルを見ることができ ます。psqlの中で \? を使って、コマンドの全リストを調べることができま す。一方で、psql のソースコードで、バックスラッシュコマンドを 出力する pgsql/src/bin/psql/describe.c ファイルを読むこともで きます。その中には、 SQL コマンドを生成する部分も含ま れます。また、 -E オプションを付けて psql を開始すると、 入力されたコマンドを実行するためのクエリを印字出力するようになります。 PostgreSQLは SQL 準拠の INFORMATION SCHEMA インター フェースを提供しますので、データベースについての情報を問い合わせるこ ともできます。
pg_ で始まるシステムテーブルでもこれらを記述することができ ます。
psql -lを使うと全てのデータベースをリストします。
それと、pgsql/src/tutorial/syscat.source を試してみてくだ さい。そこには、データベースのシステムテーブルから情報を得るために必 要な SELECT 文が沢山あります。
カラムのデータ型の変更は 8.0 以降では、 ALTER TABLE ALTER COLUMN TYPE を使うことにより間単に なりました。
それより前のバージョンでは、以下のようにします:
BEGIN;
ALTER TABLE tab ADD COLUMN new_col new_data_type;
UPDATE tab SET new_col = CAST(old_col AS new_data_type);
ALTER TABLE tab DROP COLUMN old_col;
COMMIT;
これを行なったときは、抹消された行が使っているディスク空間を回収 するためにVACUUM FULL tabをしたほうが良いかもしれません。
制限は以下のとおりです:
データベースの最大サイズ? 制限無し (32 TB のデータベースも存在します) テーブルの最大サイズ? 32 TB ロウの最大サイズ? 400 GB フィールドの最大サイズ? 1 GB テーブル内での最大ロウ数? 制限無し テーブル内での最大カラム数? カラムの型によって 250-1600 テーブル内での最大インデックス数? 制限無し
もちろん、これらは実際は無制限ではなく、ディスク容量とメモリーや スワップスペースの大きさにより制限されます。性能はこれらの値がことの ほか大きな時に煽りを受けます。
最大テーブルサイズの32TBはオペレーティングシステムによる巨大ファ イルのサポートは必要としません。巨大なテーブルは複数の1GBのファイル に分けて保存されますので、ファイルシステムの制限は重要ではありません。
デフォルトのブロックサイズを32kに増加することで、最大テーブルサイズ と行サイズと最大カラム数とを4倍にすることができます。また、最大テーブル サイズはテーブルパーティションを使って増やすこともできます。
ひとつの制限は、約2,000文字以上の長さのカラムにインデックスを付 けることができないことです。 幸いにも、そのようなインデックスは実際 は必要ありません。長いカラムのMD5ハッシュの関数インデックスは一意性 がなによりの保険で、また、フルテキストのインデックスではカラム内の 単語を検索することができます。
普通のテキストファイルを PostgreSQL のデータベースに保存するには、 最大で約5倍のディスク容量を必要とします。
例題として、各行に整数とテキスト記述を持つ 100,000行のファイルを 考えてみましょう。テキストの文字列の平均長さを20バイトと仮定すると、 フラットファイルの大きさは約2.8MB です。このデータを含む PostgreSQL データベースファイルの大きさは次のように約5.6MBと見積もることができ ます：
28 bytes: 各ロウのヘッダ(概算)
24 bytes: 整数(int)フィールドとテキスト(text)フィールド
+ 4 bytes: ページ上のタップルへのポインタ
----------------------------------------
56 bytes per row
PostgreSQL のデータページサイズは 8192バイト(8KB)なので:
8192 bytes per page
------------------- = 146 rows per database page (切り捨て)
56 bytes per row
100000 data rows
-------------------- = 685 database pages (切り上げ)
146 rows per page
685 database pages * 8192 bytes per page = 5,611,520 bytes (5.6 MB)
インデックスは、これほどのオーバヘッドは要求しませんが、インデッ クス付けされるデータを含む以上、それなりに大きくなります。
NULLはビットマップとして保存されていて、それらがわ ずかにスペースを使います。
インデックスは、すべてのクエリで使われるわけではありません。テー ブルが最小サイズより大きく、クエリでそのわずかなパーセンテージのロウ を選択する時だけ、インデックスは使われます。これはインデックススキャ ンにより起こされるランダムなディスクアクセスは、テーブルをストレート に読む順次走査よりも遅くなることがあるからです。
インデックスを使うかを決定するために、PostgreSQL はテーブルについ ての統計情報を持たなければなりません。この統計情報は、 VACUUM ANALYZEまたは、単に ANALYZE を使っ て収集することができます。統計情報を使ってオプティマイザはテーブルの 中にあるロウ数を知り、インデックスを使うべきかの決定をより正しくでき ます。統計情報は最適な結合順や結合方法を決める上でも貴重なものもあり ます。統計情報の収集は、テーブルの内容が変わる毎に繰返しなされるべ きです。
インデックスは、通常 ORDER BY や結合を行なうため には使われません。順次スキャンに続く明示的ソートは、巨大なテーブルの インデックススキャンよりも普通は高速です。
しかし、ORDER BYと組み合わされたLIMIT は、テーブルの小さな部分を返すためにたびたびインデックスを使うでしょ う。もし、オプティマイザが間違ってシーケンシャルスキャンを選択したこ
とに疑いがなければ、SET enable_seqscan TO 'off'に設定し
て、クエリをもう一度実行し、インデックススキャンがまちがいなく速くなっ
ているかどうかをみてください。
LIKE あるいは ~ のようなワイルドカード演算 子は特別な環境でしか使えません：
LIKEイン デクシングにだけ働くような、特別な
text_pattern_opsイ ンデックスを作成することもできます。
8.0より前のリリースでは、インデックスは、データ型がちょうどインデッ クスのカラムの型と一致しなければ、使えないことがしばしばありました。 おそらく、int2, int8, および numeric 等のカラムのインデックスがそう です。
オンラインマニュアルで EXPLAIN を見てください。
~演算子は正規表現照合を行ない、~* は大文字と小文字 を区別しない(case-insensitive)正規表現照合を行います。 大文字と小文 字を区別しない LIKE 演算子を ILIKE と いいます。
大文字と小文字を区別しない等値比較は次のように表現できる：
SELECT *
FROM tab
WHERE lower(col) = 'abc';
標準インデックスでは使われず、しかしながら、もし、式インデックス を作ったならそれが使われるでしょう。
CREATE INDEX tabindex ON tab (lower(col));
上記のインデックスがUNIQUEで作成された場合、カラム は大文字と小文字を格納できますが、その違いが文字ケースだけであっても 同一にはなりません。あえて特定の文字ケースをカラムに格納するには CHECK制約か、トリガーを使ってください。
以下のように、IS NULL と IS NOT NULLで、そのカラムをテストしてみます：
SELECT * FROM tab WHERE col IS NULL;
NULL状態でソートするには、IS NULL と IS NOT NULL の修飾子を ORDER BY 句の中 で使ってみます。true のものは false のものよりも高い値 として並べられますので、次の例では NULL の記載が結果リストの上部に置 かれます。
SELECT * FROM tab ORDER BY (col IS NOT NULL)
型 内部名 備考 VARCHAR(n) varchar 最大長のサイズを指定する、詰め物無し CHAR(n) bpchar 指定された固定長となるように空白が詰められる TEXT text 長さに特別な上限は無し BYTEA bytea 可変長のバイト配列(null-byte safe) "char" char 1文字
内部名にお目にかかるのは、システム・カタログを調べるときや、エラー メッセージを受け取るときです。
上記の型のうち最初の４つの型は "varlena" 型です(すなわち、ディス クの最初の４バイトがデータ長で、それの後に実際のデータが続きます)。 このように実際の空間は宣言された大きさよりも少し大きくなります。しか し、長い値は圧縮されるので、ディスク上の空間は思ったよりも小さくなります。
VARCHAR(n) は可変長の文字列を保存するのに最適です が、保存できる文字列の長さに制限があります。TEXT は長 さに制限の無い文字列の保存のためのもので、最大で 1ギガバイトです。 CHAR(n)は、VARCHAR(n)が与えられた文字 だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を 保存するのに最適です。BYTEAは、部分的に NULL のバイトを含むバイナリデータを保存するためのもの です。これらのタイプは同じくらいの性能特性をもちます。
PostgreSQL は SERIAL データ型をサポートします。カ ラム上にシーケンスを自動作成します。たとえば、
CREATE TABLE person (
id SERIAL,
name TEXT
);
は自動的に次のように翻訳されます:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);
[訳注：
CREATE UNIQUE INDEX person_id_key ON person ( id );
は、 7.3 以降は自動的には行なわれなくなりました。
]
ひとつの方法は、nextval() 関数を使ってその値を挿入する 前(before)に SEQUENCE オブジェクトから次の SERIAL 値を取り出し、それから実際に挿入をすることです。4.11.1 のテーブルの例を使うとすると、疑似言語では このようになります。
new_id = execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
そうして、new_id に保存した新しい値を他のクエリ(たとえば、
person テーブルに対する外部キー(foreign key)のように)使うと
よいでしょう。自動的に作られたSEQUENCEオブジェクトの
名前は、<table>_<serialcolumn>_seq
のようになり、このうち、table と serialcolumn はそれぞ
れテーブルの名前とSERIALカラムの名前です。
あるいは、与えられたSERIAL値を、それが既定値として 挿入された後で(after)、 currval() 関数を使って取り出す こともできます。たとえば、
execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
new_id = execute("SELECT currval('person_id_seq')");
それはありません。currval() は、すべてのユーザではありませ んが、読者のセッションに与えられた現在の値を返します。
同時性を改善するために、実行中のトランザクションに、必要に応じてト ランザクションが終了するまでロックされないようシーケンス値を与えてい ます。このためトランザクションが中断されると番号割り当てにギャップを 生じます。
PostgreSQLでつくられるすべてのロウは、WITHOUT OIDS でつくられないかぎり一意のOIDを得ます。 OIDは自動的に4バイトの整数で与えられ、それは、全イン ストレーションを通して一意な値となります。しかし、約40億でオーバーフ ローし、そして、OIDは重複をしはじめます。PostgreSQLは 内部システムテーブルを一緒にリンクするためにOID を使 います。
ユーザのテーブルのカラムに一意の番号を付けるためには、 OID ではなく SERIAL を使うのが最もよい でしょう。SERIALの連番は1つのテーブル内でのみ一意にな るからで、オーバーフローを起こしにくいと考えられます。 8バイトのシーケンス値を保存するために、SERIAL8があり ます。
CTID は、特定の物理ロウをブロックとオフセットの値 で識別するために使われます。CTIDは、ロウが修正された り再読込みされたときに変わります。また、物理ロウを差すためにインデッ クスの記載に使われます。
おそらく、システムの仮想メモリーを全て使い果たしてしまっている可 能性があるか、カーネルがあるリソースについてもつ制限値が低すぎる可能 性があります。postmaster を始動する前にこれを試してみてください：
ulimit -d 262144
limit datasize 256m
シェルによって、どちらかひとつが成功するでしょうが、これはプロセスの
データセグメント制限をより高く設定し、たぶんクエリが完結するようにな
るでしょう。このコマンドは現行のプロセスと、このコマンドを走らせた後
に作られる全てのサブプロセスについて適用されます。バックエンドがとて
も多くのデータを返すためにSQL クライアントで問題が続
いているのであれば、クライアントを開始する前にこれを試してみてくださ
い。
psql から SELECT version(); をタイプします。
CURRENT_TIMESTAMPを使います:
CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
PostgreSQL は SQL 標準構文を使う外部結合(アウタージョイン)をサポー トします。ここに 2つの例題があります。
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
あるいは
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);
これらの象徴的なクエリでは t1.col を t2.col と結合して、t1 の結合されなかったロウ(t2 と一致しなかったロウ)も返しています。RIGHT 結合は t2 の結合されなかったロウを加えるでしょう。FULL 結合は、一致したロウに t1 と t2 からは結合されなかったロウを返すでしょう。OUTER という言葉はオプションで LEFT, RIGHT, または FULL などの結合を仮定されています。通常、結合はINNER結合と呼ばれます。
現行のデータベース以外への問い合わせの方法はありません。というの もPostgreSQLがデータベース仕様のシステムカタログを読み込むためで、そ こには、たとえそのふりをするだけにしろ、データベースを越えて問い合わ せをするすべがありません。
contrib/dblink はデータベース間(cross-database)の問い合わ せを関数呼出しにより許します。もちろん、クライアントは同時に接続を別 のデータベースへも張らなくてはならず、結果をクライアント側でマージし なくてはなりません。
集合を返す関数(Set Returning Functions): http://techdocs.postgresql.org/guides/SetReturningFunctions を使うと簡単です
。PL/PgSQL は関数スクリプトをキャッシュし、不幸にもその副作用で、 PL/PgSQL関数が一時テーブルにアクセスする場合、後でそのテーブルを消し て作りなおされ、関数がもう一度呼び出されると、その関数はキャッシュし ている関数の内容はまだ古い一時テーブルを差し示したままだからです。 この、解決策として、PL/PgSQLの中で EXECUTE を一時テー ブルへのアクセスのために使います。そうすると、クエリは毎回パースをや り直しされるようになります。
「レプリケーション」と一言でいいますが、レプリケーションをする ための技術はいくつかあり、それぞれ、利点と欠点があります。
マスタ／スレーブのレプリケーションは、読み／書きのクエリを受け取 るシングルマスタが可能で、スレーブでは 読み／SELECTの 問い合わせだけを受け付けることができます。最も人気がある、フリーで利 用できる、マスタ−スレーブのPostgreSQLレプリケーションソリューション は、 Slony-I です。
マルチ−マスタのレプリケーションは、読み／書きのクエリを受けと り、複数のレプリケートさせるコンピュータに送ることができます。この機 能は、サーバ間の変更の同期が必要なため、性能に重大な衝撃を与えます。 Pgcluster は、 このようなソリューションとしてPostgreSQLのためにフリーで利用できるも のとして、最も人気があります。
この他にも、商用やハードウェア−ベースのレプリケーションソリュー ションがいろいろなレプリケーションモデルをサポートしています。
もっとも一般的な原因は、テーブルを作成する際に、テーブルやカラムを 囲う二重引用符の使用です。二重引用符を使うと、テーブルとカラムの名前 （識別子と呼びます）は大文字と小文字の区別 をして格納されます。したがって、pgAdminのようにテーブル作成のときに 自動的に二重引用符を使うものはクエリの中でそれらの名前を使うときに 二重引用符を付けなくてはならないことを意味します。このため、識別子 を認識させるためには以下のいずれかを心がけます。
createdb -Eコマンドオプションに UTF8 あるいは EUC_JP のエンコーディングを指定してデータベースを作成すか、次のように エンコーディングを指定してデータベースを作成してください。
CREATE DATABASE dbname WITH ENCODING 'UTF8';
もしくは、
CREATE DATABASE dbname WITH ENCODING 'EUC_JP';
psqlの中でクライアントのエンコーディングを指定してください。
SET client_encoding TO 'SJIS'
PostgreSQLデータベースのエンコーディングに使える日本語文字コード は EUC_JP か UTF-8(UNICODE) であるため、Shift-JIS表示のコマンドプロ ンプトからは、client_encodingを設定しておかないと、日本語を表示する 際に文字化けがおきます。
[訳注：
日本語版の製作については以下の通りです。
最終更新日: 2006年05月19日
翻訳者: 桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>)
このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます):
田仲 稔(Minoru TANAKA <Tanaka.Minoru at keiken.co.jp>)
石井 達夫(Tatsuo ISHII <t-ishii at sra.co.jp>)
齊藤 知人(Tomohito SAITOH <tomos at elelab.nsc.co.jp>)
馬場 肇(Hajime BABA <baba at kusastro.kyoto-u.ac.jp>)
岡本 一幸(Kazuyuki OKAMOTO <kokamoto at itg.hitachi.co.jp>)
小菅 昭一(Shoichi Kosuge <s-kosuge at str.hitachi.co.jp>)
山下 義之(Yoshiyuki YAMASHITA <dica at eurus.dti.ne.jp>)
境 真太郎(Sintaro SAKAI <s_sakai at mxn.mesh.ne.jp>)
生越 昌己(Masami OGOSHI <ogochan at zetabits.com>)
石川 俊行(Toshiyuki ISHIKAWA <tosiyuki at gol.com>)
本田 茂広(Shigehiro HONDA <fwif0083 at mb.infoweb.ne.jp>)
せせ じゅん(Jun SESE <sesejun at linet.gr.jp>)
神谷 英孝(Hidetaka KAMIYA <hkamiya at catvmics.ne.jp>)
菅原 敦(Atsushi SUGAWARA <asugawar at f3.dion.ne.jp>)
稲葉 香理(Kaori Inaba <i-kaori at sra.co.jp>)
石井 達夫(Tatsuo Ishii <t-ishii at sra.co.jp>)
をはじめ、ポストグレスに関する話題豊富な日本語PostgreSQLメーリングリスト、
和訳のきっかけを作ってくれたり、いつもチェックをしてくれる
JF(Linux Japanese FAQ)プロジェクト、FreeBSD ドキュメンテーションプロジェクト
の方々、それから、直接あるいは間接的にかかわってくださるすべてのオープンソース
コミュニティのみなさまに感謝いたします。
この翻訳文書は 本家 "Frequently Asked Questions" のページに "Japanese FAQ"
という項目であります。
また、最新版は以下のサイトにあります。
http://www.PostgreSQL.jp/wg/jpugdoc/ 「JPUG文書・書籍関連分科会」
http://www.linux.or.jp/JF/JFdocs/INDEX-database.html 「Linux JFプロジェクト」
http://www.rccm.co.jp/~juk/pgsql/ 「PostgreSQL Notes for Japanese」（翻訳者ページ）
なお、この和訳に関するご意見・ご質問は(juk at PostgreSQL.jp)までお寄せください。
（※ メールアドレスの " at " は適切に直してください。半角の "@" です。）
]