From ce8a4ffca620cdb1369c29f1a2a5396d4b118e1a Mon Sep 17 00:00:00 2001
From: Bruce Momjian
-原文最終更新日: Mon Mar 29 00:07:11 EST 2004
PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ)
現在の維持管理者: Bruce Momjian (pgman@candle.pha.pa.us)
@@ -42,7 +42,7 @@ http://www.PostgreSQL.org/docs/faqs/FAQ.html
この和訳についてお気づきの点は(juk at PostgreSQL.jp)までメールでお寄せ下さい。
- 2003年09月20日 桑村 潤
+ 2004年08月22日 桑村 潤
]
@@ -92,6 +92,7 @@ http://www.PostgreSQL.org/docs/faqs/FAQ.html
3.8) 接続しようとするときに 'Sorry, too many clients' が出るのはなぜですか?
3.9) pgsql_tmp ディレクトリの中には何がありますか?
3.10) PostgreSQLのメジャーリリースをアップデートするのにダンプとリストアをしなくてはならないのはなぜですか?
+3.11) ハードウェアにはどんなコンピュータを使えばよいですか?
@@ -142,7 +143,7 @@ http://www.PostgreSQL.org/docs/faqs/FAQ.html
Post-Gres-Q-L.(ポスト - グレス - キュー - エル) と発音します。 +
Post-Gres-Q-L(ポスト - グレス - キュー - エル) と発音します。 この発音を聞きたい人のために、オーディオファイルを http://www.postgresql.org/postgresql.mp3 に用意してあります。
PostgreSQL は次世代 DBMS 研究用のプロトタイプであった POSTGRES データベース管理システムの改良版です(このため、今でもときどき "Postgres" と呼ばれることがあります)。PostgreSQL は POSTGRES の強力なデータ・モデルと豊富なデータ・タイプ(型)を保持しながら、POSTGRES で使われた PostQuel 問い合わせ言語を、拡張した SQL のサブセットに置き換えています。PostgreSQL は無料で完全なソースを利用できます。 @@ -150,7 +151,7 @@ http://www.PostgreSQL.org/docs/faqs/FAQ.html "http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html">http://www.PostgreSQL.org/docs/faqs/FAQ_DEV.html にある開発者向けのFAQを見てください。
-Postgres95-1.01 の中心的な開発者は Andrew Yu と Jolly Chen でしたが、その他大勢の人々がこのコードの移植、テスト、デバグ、および、改良に参加しました。PostgreSQL の派生元コードである POSTGRES はカリフォルニア大学バークレイ校において、 Michael Stonebraker 教授の指揮のもと、多くの学生、卒業生、本職のプログラマたちの努力により作られました。 +
Postgres95-1.01 の中心的な開発者は Andrew Yu と Jolly Chen でしたが、その他大勢の人々がこのコードの移植、テスト、デバグ、および、改良に参加しました。PostgreSQL の派生元コードである Postgres はカリフォルニア大学バークレイ校において、 Michael Stonebraker 教授の指揮のもと、多くの学生、卒業生、本職のプログラマたちの努力により作られました。
バークレイにおけるこのソフトウェアのもとの名前は Postgres でしたが、SQL の機能が追加された 1995 年にその名前は Postgres95 に変更され、1996 年の終りにその名前は PostgreSQL に変更されました。 @@ -235,30 +236,19 @@ MODIFICATIONS.
Win32 libpq ライブラリと psql を作るために、win32.mak が配布に含まれてます。PostgreSQLは ODBC クライアントとも通信できます。
サーバ
+現在、Cygnus Unix/NT 移植ライブラリの Cygwin を使って、PostgreSQL データベースサーバは Windows NT と Win2k 上で稼働しています。配布に含まれるpgsql/doc/FAQ_MSWIN、あるいは、 http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWINにある MS Windows FAQ をご覧下さい。
+MS Win NT/2000/XP ネイティブ版への移植が現在進行中です。もっと詳しいWindows版PostgreSQLの近況は、http://techdocs.postgresql.org/guides/Windowsと http://momjian.postgresql.org/main/writings/pgsql/win32.html を見てください。
-- Windows-Native サーバー & クライアントパッケージが斉藤さんにより - 維持管理されています。 - http://hp.vector.co.jp/authors/VA023283/PostgreSQL.html - (Windows-Native Server&Client Package for PostgreSQL by Hiroshi Saito) - http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html +-Novell Netware 6 の移植もあります。 + http://forge.novell.com.
-
主要なメーリング・リストは: pgsql-general@PostgreSQL.orgです。PostgreSQL に関することであれば議論ができます。このリストへの参加のは、電子メールの本文(Subject 行ではありません)に次の2行を書いて、
+主要なメーリング・リストは: pgsql-general@PostgreSQL.orgです。PostgreSQL に関することであれば議論ができます。このリストへの参加は、電子メールの本文(Subject 行ではありません)に次の2行を書いて、
subscribe end @@ -315,7 +306,7 @@ href="ftp://ftp.PostgreSQL.org/pub/">ftp://ftp.PostgreSQL.org/pub/ endと書いてbugs-request@PostgreSQL.org +HREF="mailto:pgsql-bugs-request@PostgreSQL.org">pgsql-bugs-request@PostgreSQL.org へ電子メールを送って下さい。 @@ -332,45 +323,35 @@ HREF="mailto:bugs-request@PostgreSQL.org">bugs-request@PostgreSQL.org http://www.PostgreSQL.org -
EFNetに #PostgreSQL という IRC チャンネルもあります。 +
Freenode および EFNetに #PostgreSQL という IRC チャンネルもあります。
UNIX コマンドで
irc -c '#PostgreSQL' "$USER" irc.phoenix.net.
あるいは、
irc -c '#PostgreSQL' "$USER" irc.freenode.net.
を使って参加できます。
[訳注:
- 1999年7月23日、日本PostgreSQLユーザー会(にほん ぽすとぐれす ゆーざー かい)、略称JPUG
- が設立されました。JPUG は非営利組織で、PostgreSQLを利用する人達の相互協力の場となっています。
- 2003年5月17日の総会を以って、「日本PostgreSQLユーザ会」に名称を改めました。
+ 1999年7月23日、日本ポストグレスユーザー会、略称JPUGが設立されました。
+ JPUG は非営利組織で、PostgreSQLを利用する人達の相互協力の場となっています。
+ (2003年5月17日、「日本PostgreSQLユーザ会」に名称を改めました。)
正会員の会費は無料ですが、協賛会員の会費と会員の積極的な貢献が会の運営を助けています。
詳しくは、JPUG のWeb サイト:
http://www.PostgreSQL.jp/
をご覧ください。会員登録も可能となっています。
- 1990年代中ごろより、ポストグレスの日本語メーリング・リストを石井 達夫さんが主催しています。詳細は、
- http://www.sra.co.jp/people/t-ishii/PostgreSQL/ML/info.html
- をご覧下さい。アーカイブを、いわきりさんのpgsql-jp ML検索システム
- http://datula.mio.org/~iwakiri/pgsql_jp/
- で検索することもできます。
- ]
+
+ 日本語のIRCチャンネル '#PostgreSQL*jp' も存在します。
商用サポート会社のリストはhttp://techdocs.postgresql.org/companies.phpにあります。
-
-
- [訳注:
- 日本では、SRA Inc. オープンシステム事業部 にて商用サポートが行なわれています。
- ミラクル・リナックス株式会社 で "Miracle Linux for PostgreSQL" の販売とサポートが
- 開始されました。
- ]
-
-
-PostgreSQL の最新版はバージョン 7.4.2 です。
+PostgreSQL の最新版はバージョン 7.4.5 です。我々は、6〜8カ月毎にメジャーリリースを行なうことを計画しています。
@@ -508,8 +489,6 @@ http://www.PostgreSQL.org/docs/awbook.htmlhttp://www.PostgreSQL.org/bugs/bugs.phpPostgreSQL BugTool (バグツール)のページを訪れてみて下さい。 バグレポートを提出する仕方についての手引と指針があります。
-その前に http://PostgreSQL.orgにある最新の FAQ をチェックして下さい。
-それと同時に ftp サイト ftp://ftp.PostgreSQL.org/pub/で、もっと新しいバージョンの PostgreSQL あるいはパッチをさがしてみて下さい。
質の良い基盤はオープンソース・プロジェクトにとってはとても大切なもので、前進する勢いを失うプロジェクトの分裂を回避します。
もちろん、この基盤は安いものではありません。維持し続けるためには毎月あるいは一時の経費がかかります。もし、あなたやあなたの会社に、こうした努力のための資金を助けるために施すことができるようでしたら、https://store.pgsql.com/shopping/から寄付をお願いします。 +href="http://store.pgsql.com/shopping/">http://store.pgsql.com/shopping/から寄付をお願いします。
また、Webページには PostgreSQL,Inc とありますが、そこの"義援(contributions)"アイテムは PostgreSQL プロジェクトをサポートするためだけのためで、決して特定の会社のための資金のためではありません。もし、手形(check)の方が都合がよければ連絡先の住所へお送り下さい。
@@ -636,7 +612,7 @@ Programmer's Guideもちろん、PostgreSQL へのグラフィカルインターフェイスがいくつかあります。 その中にPgAccess http://www.pgaccess.com + href="http://www.pgaccess.org">http://www.pgaccess.org も含まれます。 PgAdmin III (http://www.pgadmin.org)もあります。 @@ -649,8 +625,6 @@ PhpPgAdmin ( http://phppgadmin.sourceforge.net/ ) はPostgreSQLへのWebベースの インターフェイスを提供します。 -
PgAccess と呼ばれる素晴らしいグラフィカル・ユーザ・インターフェイスがあり、この配布と共に出荷されます。PgAccess にはレポート・ジェネレータもあります。Web ページはhttp://www.pgaccess.org/です。 -
より詳細なリストについては、http://techdocs.postgresql.org/guides/GUITools をご覧ください。
@@ -666,15 +640,13 @@ PhpPgAdmin (以下のインターフェイスはPostgreSQLの配布に含まれています。
その他の利用可能なインターフェイスは http://www.PostgreSQL.org/interfaces.html - および、 http://gborg.postgresql.org のDrivers/Interfacesのセクションにあります。
@@ -707,7 +679,7 @@ href="http://www.PostgreSQL.org/interfaces.html">http://www.PostgreSQL.org/interカーネルが共有メモリーを持つ設定になっていなかったか、でなければ、カーネルに対して使える共有メモリーの大きさを大きく設定する必要があります。具体的な大きさは、使っているアーキテクチャとpostmaster を走らせるときに設定するバッファの数とバックエンドプロセスに依存します。ほとんどのシステムでは、既定値のバッファサイズのままで、少なくとも約1MBが必要です。 PostgreSQL Administrator's Gide + "http://www.PostgreSQL.org/docs/view.php?version=current&idoc=1&file=kernel-resources.html">PostgreSQL Administrator's Guide に共有メモリーとセマフォについての情報の詳細がありますのでご覧ください。
@@ -722,7 +694,7 @@ href="http://www.PostgreSQL.org/interfaces.html">http://www.PostgreSQL.org/interもし、エラーメッセージがなにか他のものであれば、カーネルの構成でまったくセマフォのサポートをしていないかもしれません。 -PostgreSQL Administrator's Gide に共有メモリーとセマフォについての情報の詳細があります。
+PostgreSQL Administrator's Guide に共有メモリーとセマフォについての情報の詳細があります。@@ -730,7 +702,7 @@ PostgreSQL Administrator's Gide
既定値では、PostgreSQL は unix ドメインソケットを使うローカルマシンからの接続しか許しません。postgresql.conf の中の tcpip_sockets を有効にし、$PGDATA/pg_hba.conf ファイルを適切に直して、ホスト主導型の認証を使わないかぎりは他のマシンからは接続できないでしょう。これによりTCP/IPの接続が可能になります。 -
操作不能なセマフォも過度のデータベースアクセス中にクラッシュを引き起こすことがあります。 +
postmasterが同時始動できるバックエンドプロセスに対する制限数を増やす必要があります。
既定の最大プロセスは32プロセスです。-Nに適切な値を引数にしてpostmasterを再起動するか、PostgreSQL.conf を修正することによって、その値を増やすことができます。 -既定の構成では-Nは最大1024まで設定できます。もし、もっと必要であればinclude/config.hの中のMAXBACKENDSを増加させ、再構築します。もし、望むならconfigureの --with-maxbackends切替を使って、-Nの既定値を構成時に設定できます。 -
もし、-N を 32よりも大きくするのであれば、-Bも既定の64より大きい値に増加させなくてはならないし、-B は少なくとも -N の2倍はなくてはならず、おそらく最高性能を望むならばそれより大きい値が必要なはずです。バックエンドプロセスをたくさんにすると、いろいろなUnixカーネル構成パラメータも増やすことが必要になるかもしれません。 共有メモリー・ブロックの最大値(SHMMAX)、 セマフォの最大数(SEMMNSとSEMMNI)、 プロセスの最大数(NPROC)、 ユーザ毎の最大プロセス数(MAXUPRC)、 -開くファイルの最大数(NFILEとNINODE +開くファイルの最大数(NFILEとNINODE) も確認事項に含まれます。 PostgreSQLに許されるバックエンドのプロセス数が制限されているのは、 システムのリソースを使い果してしまうことを避けるためです。 @@ -819,12 +789,19 @@ PostgreSQL pg_options は PostgreSQL.conf になっています。) ] +
-PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から 7.2.1 へのアップグレードにはダンプとリストアの必要はありません。しかし、メジャーリリース(たとえば、7.2から7.3へのような)では、システムテーブルやデータファイルの内部フォーマットの変更をしばしば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファイルのための後方互換性を維持することができません。ダンプは汎用フォーマットでデータを出力し、それを新しい内部フォーマットに読み込むことができます。 +PostgreSQLチームはマイナーリリースでは小さな変更しか行ないませんので、7.2 から 7.2.1 へのアップグレードにはダンプとリストアの必要はありません。しかし、メジャーリリース(たとえば、7.2から7.3へのような)では、システムテーブルやデータファイルの内部フォーマットの変更をしばしば行ないます。これらの変更はたいてい複雑で、そのため我々はデータファイルのための後方互換性を維持することができません。ダンプは汎用フォーマットでデータを出力し、それを新しい内部フォーマットに読み込むことができます。
++ディスク上でのフォーマットに変更のない同一リリースでは、アップグレードは、ダンプ/リストアではなく、pg_upgrade スクリプトを使うことができます。リリースノートには、pg_upgrade が利用可能なリリースかどうか記されています。
+ ++
-同一リリースではディスク上でのフォーマットに変更はないので、アップグレードにはダンプ/リストアではなく、pg_upgrade スクリプトを使うことができます。リリースノートには、pg_upgrade が利用可能なリリースかどうか記されています。
+PCハードウェアはほとんど互換性がありますので、ほとんどの人は、すべてのPCハードウェアが同じ品質だと思い込む傾向があります。しかし、それは間違いです。ECC RAM、SCSI、および、高品質マザーボードは、安いハードウェアに比べると、より信頼性が高く、より性能も良いのです。PostgreSQL はほとんどのハードウェアで稼働しますが、信頼性や性能が重要な場合は、ハードウェアのオプションを研究することが賢明です。メーリングリストでもハードウェアオプションとトレードオフについて議論することができます。 +
- psqlの中で、 \dt コマンドを使ってテーブルを見ます。psql の中のコマンドの完全なリストには \? を使えます。あるいは、psqlのソースコードのpgsql/src/bin/psql/describe.cファイルを見るることもできて、その中にはpsqlのバックスラッシュコマンドの出力を生成するSQLコマンドが含まれています。また、psqlを -E オプションと一緒に開始すると、実行させたコマンドを実行するために使う問い合わせを出力するようになります。PostgreSQLはまた、SQLi対応の INFORMATION SCHEMA インターフェースを用意していて、データベースについての情報を得るために問い合わせを使うことができます。 + psqlの中で、 \dt コマンドを使ってテーブルを見ます。psql の中のコマンドの完全なリストには \? を使えます。あるいは、psqlのソースコードのpgsql/src/bin/psql/describe.cファイルを見ることもできて、その中にはpsqlのバックスラッシュコマンドの出力を生成するSQLコマンドが含まれています。また、psqlを -E オプションと一緒に開始すると、実行させたコマンドを実行するために使う問い合わせを出力するようになります。PostgreSQLはまた、SQLi対応の INFORMATION SCHEMA インターフェースを用意していて、データベースについての情報を得るために問い合わせを使うことができます。
@@ -884,7 +861,7 @@ PostgreSQL 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 DROP tab COLUMN old_col; + ALTER TABLE tab DROP COLUMN old_col; COMMIT; @@ -902,14 +879,14 @@ PostgreSQL フィールドの最大サイズ? 1GB テーブル内での最大ロウ数? 制限無し テーブル内での最大カラム数? カラムの型により250-1600 -テーブル内での最大インデクス数? 制限無し +テーブル内での最大インデックス数? 制限無しもちろん、これらは実際は無制限ではなく、ディスク容量とメモリーやスワップスペースの大きさにより制限されます。性能はこれらの値がことのほか大きな時に煽りを受けます。
最大テーブルサイズの32TBはオペレーティングシステムによる巨大ファイルのサポートは必要としません。巨大なテーブルは複数の1GBのファイルに分けて保存されますので、ファイルシステムの制限は重要ではありません。 -
デフォルトのブロックサイズを32kにすることで、最大テーブルサイズと最大カラム数とが4倍させることができます。 +
デフォルトのブロックサイズを32kにすることで、最大テーブルサイズと最大カラム数とを4倍にすることができます。
@@ -924,23 +901,23 @@ PostgreSQL ファイルの大きさは次のように約6.4MBと見積もることができます:
- 36 bytes: 各ロウのヘッダ(概算) + 32 bytes: 各ロウのヘッダ(概算) 24 bytes: 整数(int)フィールドとテキスト(text)フィールド + 4 bytes: ページ上のタップルへのポインタ ---------------------------------------- - 64 bytes per row + 60 bytes per row PostgreSQL のデータページサイズは 8192バイト(8KB)なので: 8192 bytes per page - ------------------- = 128 rows per database page (切り上げ) - 64 bytes per row + ------------------- = 136 rows per database page (切り捨て) + 60 bytes per row 100000 data rows - -------------------- = 782 database pages + -------------------- = 782 database pages (切り上げ) 128 rows per page -782 database pages * 8192 bytes per page = 6,406,144 bytes (6.4 MB) + 735 database pages * 8192 bytes per page = 6,021,120 bytes (6 MB)
@@ -952,8 +929,9 @@ PostgreSQL
psql にはいろいろなバックスラッシュ・コマンドがあり、こうした情報を表示します。バックスラッシュ・コマンドの種類を見るには \? を使って下さい。 -
また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。また、pg_ で始まるシステムテーブルにも記述されています。さらに、psql -l はすべてのデータベースをリスト表示します。 +
psql にはいろいろなバックスラッシュ・コマンドがあり、こうした情報を表示します。バックスラッシュ・コマンドの種類を見るには \? を使って下さい。また、pg_ で始まるシステムテーブルにも記述されています。さらに、psql -l はすべてのデータベースをリスト表示します。 + +
また、pgsql/src/tutorial/syscat.source ファイルを走らせてみて下さい。それは、沢山の SELECT 文により必要な情報をデータベースのシステム・テーブルから取り出して例示してくれます。
もし、オプティマイザが間違ってシーケンシャルスキャンを選択したことに疑いがなければ、SET enable_seqscan TO 'off'
を使ってインデクススキャンでまちがいなく速くなっているかをテストをしてみてください。
もし、オプティマイザが間違ってシーケンシャルスキャンを選択したことに疑いがなければ、SET enable_seqscan TO 'off'
を使ってインデックススキャンでまちがいなく速くなっているかをテストをしてみてください。
LIKE あるいは ~ のようなワイルドカード演算 子は特別な環境でしか使えません: @@ -1081,13 +1059,6 @@ Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57. - - -
- WHERE lower(textfield) LIKE lower(pattern) -- -
Type Internal Name Notes -------------------------------------------------- -CHAR(n) bpchar 指定された固定長となるように空白が詰められる -"char" char 1文字 VARCHAR(n) varchar 最大長のサイズを指定する、詰め物無し +CHAR(n) bpchar 指定された固定長となるように空白が詰められる TEXT text 長さに上限の無いテキスト BYTEA bytea 可変長のバイト配列(null-byte safe) +"char" char 1文字
内部名にお目にかかるのは、システム・カタログを調べるときや、エラーメッセージを受け取るときです。 @@ -1114,7 +1085,7 @@ BYTEA bytea
上記の型のうち最初の4つの型は "varlena" 型です(すなわち、ディスクの最初の4バイトがデータ長で、それの後に実際のデータが続きます)。このように実際の空間は宣言された大きさよりも少し大きくなります。しかし、これらのデータ型はTOASTにより圧縮されたり複数ロウに渡って保存されたりして、ディスク上の空間は思ったより小さくなります。 -
VARCHAR(n) は可変長の文字列を保存するのに最適ですが、保存できる文字列の長さに制限があります。TEXT は長さに制限の無い文字列の保存ためのもので、最大で 1ギガバイトです。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を保存するのに最適です。BYTEAは、部分的にNULL のバイトを含むバイナリデータを保存するためのものです。これらのタイプは同じくらいの性能特性をもちます。
+VARCHAR(n) は可変長の文字列を保存するのに最適ですが、保存できる文字列の長さに制限があります。TEXT は長さに制限の無い文字列の保存のためのもので、最大で 1ギガバイトです。 CHAR(n)は、VARCHAR(n)が与えられた文字だけを保存するのに対し、ブランクを詰め込んでいつも同じ長さで文字列を保存するのに最適です。BYTEAは、部分的にNULL のバイトを含むバイナリデータを保存するためのものです。これらのタイプは同じくらいの性能特性をもちます。
また、各ロウのOIDフィールドを一意値として使うこともできます。しかしながら、もしもデータベースをダンプしてリロードする必要がある場合は、OIDを温存するためにpg_dump で -oオプションを使うか、または、COPY WITH OIDSオプションを使う必要があります。 - Bruce Momjian の(http://www.PostgreSQL.org/docs/aw_pgsql_book)の Numbering Rowsの章にありあます。 -
- CREATE TABLE new (old_oid oid, mycol int); - SELECT old_oid, mycol INTO new FROM old; - COPY new TO '/tmp/pgtable'; - DELETE FROM new; - COPY new WITH OIDS FROM '/tmp/pgtable'; - + CREATE TABLE new_table(mycol int); + SELECT oid AS old_oid, mycol INTO tmp_table FROM old_table; + COPY tmp_table TO '/tmp/pgtable'; + COPY new_table WITH OIDS FROM '/tmp/pgtable'; + DROP TABLE tmp_table;
OID は、4バイトの整数として保存されているので、40億を越えると溢れてしまうでしょう。誰もこれが起きたと報告してくる人はいませんでしたが、そうなる前にこの制限を取り除くことを計画しています。 @@ -1269,7 +1234,7 @@ href="http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glo
CURRENT_TIMESTAMPを使います:
- CREATE TABLE test (x int, modtime timestamp DEFAULT >CURRENT_TIMESTAMP ); + CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
@@ -1284,7 +1249,7 @@ href="http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary/glo
SELECT * FROM tab - WHERE col1 IN (SELECT subcol FROM subtab) + WHERE col IN (SELECT subcol FROM subtab)を、置き換えて:
@@ -1313,7 +1278,7 @@ PostgreSQL FROM t1 LEFT OUTER JOIN t2 USING (col);-これらの象徴的な問い合わせでは t1.col を t2.col と結合して、t1 の結合されなかったロウ(t2 と一致しなかったロウ)も返しています。RIGHT 結合は t2 の結合されなかったロウを加えるでしょう。FULL 結合は、一致したロウに t1 と t2 からは結合されなかったロウを返すでしょう。OUTER という言葉はオプションで LEFT, RIGHT, または FULL などの結合を仮定されています。 +これらの象徴的な問い合わせでは t1.col を t2.col と結合して、t1 の結合されなかったロウ(t2 と一致しなかったロウ)も返しています。RIGHT 結合は t2 の結合されなかったロウを加えるでしょう。FULL 結合は、一致したロウに t1 と t2 からは結合されなかったロウを返すでしょう。OUTER という言葉はオプションで LEFT, RIGHT, または FULL などの結合を仮定されています。通常、結合はINNER結合と呼ばれます。 以前のリリースでは外部結合(outer join)をUNION と NOT IN を使ってシミュレートできます。 たとえば、tab1 と tab2 を結合するときは、次の問い合わせで二つのテーブルを外部結合します。 @@ -1341,7 +1306,7 @@ PostgreSQL
7.3では関数から、複数行のや複数カラムを簡単に返せます。 +
7.3では関数から、複数のロウや複数カラムを簡単に返せます。 http://techdocs.postgresql.org/guides/SetReturningFunctions。 @@ -1425,7 +1390,7 @@ http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php
[訳注: 日本語版の製作については以下の通りです。 - 最終更新日: 2004年04月28日 + 最終更新日: 2004年08月22日 翻訳者: 桑村 潤 (Jun Kuwamura <juk at PostgreSQL.jp>) このFAQの和訳の作成にあたり協力をしてくださった方々(敬称は略させていただきます): @@ -1447,8 +1412,8 @@ http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php 稲葉 香理(Kaori Inaba <i-kaori at sra.co.jp>) をはじめ、ポストグレスに関する話題豊富な日本語ポストグレス・メーリングリスト、 -和訳のきっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)プロジェクト、その他、 -直接あるいは間接的にかかわっているすべてのオープンソースコミュニティーの皆さんに感謝します。 +和訳のきっかけを作ってくれた JF(Linux Japanese FAQ Mailing List)プロジェクト、 +その他、直接あるいは間接的にかかわっているすべてのオープンソースコミュニティーの皆さんに感謝します。 日本語版のこの文書は、以下からもたどれます。 http://www.rccm.co.jp/~juk/pgsql/(FAQ和訳 PostgreSQL についてよくある質問) -- cgit v1.2.3