PSQL データベース
 
このページをシェアする                  
PSQL データベース
オブジェクト名、名前付きデータベースおよび DSN の詳細
ここでは以下の項目について取り上げます。PSQL データベースの概念セクションで各項目を詳しく説明します。
名前付きデータベース
メタデータ
識別子とオブジェクト名
デフォルトのデータベースと現在のデータベース
ファイル構造
アクセス方法
クライアント/サーバー通信
データベース コード ページ
ODBC DSN 作成オプション
idshosts ファイルの使用
PSQL データベースの概念
以下のセクションでは、PSQL データベースの概念について説明します。
名前付きデータベース
メタデータ
識別子とオブジェクト名
デフォルトのデータベースと現在のデータベース
ファイル構造
アクセス方法
クライアント/サーバー通信
データベース コード ページ
ODBC DSN 作成オプション
idshosts ファイルの使用
名前付きデータベース
名前付きデータベース(DBname とも呼ばれます)は論理名付きのデータベースです。ユーザーはデータベースが存在する場所を知らなくても、この名前でそのデータベースを識別することができます。PSQL では、すべてのデータベースが名前付きデータベースである必要があります。データベースに名前を付ける際は、その名前を特定の辞書ディレクトリのパスおよび 1 つまたは複数のデータ ファイルのパスに関連付けるようにします。
名前付きデータベースへは、さまざまなアクセス方法で接続されます。たとえば、ODBC アクセスの場合は名前付きデータベースを指すデータ ソース名(DSN)を設定する必要があります。複数の DSN が同じ名前付きデータベースを指すことができます。『ODBC Guide』の ODBC データベース アクセスを参照してください。その他のアクセス方法の場合、アプリケーション開発者が、それぞれのアクセス方法の API を使用して名前付きデータベースに接続することができます。PSQL ドキュメントの開発者向けガイドを参照してください。
メモ: 名前付きデータベースを使用する場合、管理者レベルまたは Pervasive_Admin セキュリティ グループのメンバーであるオペレーティング システムのユーザー名で、データベース エンジンが存在するコンピューターにログインする必要があります。
名前付きデータベースを作成する最も簡単な方法は、PSQL Control Center を使用することです。『PSQL User's Guide』の新規データベースを作成するにはを参照してください。アプリケーション開発者は別のアクセス方法の API を用いて名前付きデータベースを作成することもできます。たとえば、SQL の場合は CREATE DATABASE、DTI の場合は PvCreateDatabase()、ADO.NET の場合は Data Access Application Block を参照してください。
メタデータ
リレーショナル エンジンでは、メタデータでバージョン 1(V1)とバージョン 2(V2)という 2 つのバージョンをサポートします。メタデータ バージョン 2 では、多くの識別子に最大 128 バイトの名前を付けることができ、ビューおよびストアド プロシージャを許可し、メタデータ バージョン 2 固有の DDF(データ辞書ファイル)を持つことができます。
ODBC Guide』の SQL 文法のサポートを参照してください。
識別子とオブジェクト名
識別子は、データベースの名前、またはデータベース内の列、テーブル、プロシージャやその他名前付きオブジェクトの名前です。識別子は、通常の識別子またはデリミター(区切り記号)付きの識別子として指定されます。
通常の識別子
通常の識別子とは、二重引用符で囲まれていない識別子のことです。通常の識別子は大文字または小文字の文字で始まる必要があります。識別子の残りの部分は大文字または小文字の文字、数字、および有効な文字の任意の組み合わせで構成されます。
通常の識別子に予約語を使用することはできません。
通常の識別子は大文字小文字を区別しません。
デリミター付き識別子
デリミター付き識別子とは、二重引用符で囲まれた識別子のことです。デリミター付き識別子は、有効な文字から成る任意の文字列と、それを囲む二重引用符で構成されます。
推奨できる使用法ではありませんが、デリミター付き識別子には予約語も使用できます。たとえば、INSERT は通常の識別子としての使用は許可されませんが、"INSERT" はデリミター付き識別子としては許可されます。識別子がキーワードでもある場合は二重引用符で囲む必要があります。たとえば、SELECT "password" FROM my_pword_tbl となります。"password" は SET PASSWORD ステートメントのキーワードなので二重引用符で囲みます。
識別子の制限
上に挙げた全般的な制限以外に、各種の識別子に特有の制限を次の表に一覧表示します。
表 1 識別子の種類別の制限
識別子
長さ制限
(バイト単位)
無効な文字1
注記
V12
V23
20
128
\ / : * ? " < > |
先頭は文字でなければなりません
ヌルにすることはできません
データベース
20
20
` ~ ! @ # $ % ^ & * ( ) _ - + = } ] { [ | \ : ; " < , ' > . ? /
先頭は文字でなければなりません
関数(ユーザー定義)
30
128
通常の識別子の場合:
` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < , ' > . ? /
文字、数字、およびアンダースコア("_")が有効です
先頭は文字でなければなりません
デリミター付き識別子の場合:
なし
名前を二重引用符で囲む必要があります
グループ
30
128
\ / : * ? " < > | (および空白文字)
MASTER にすることはできません
インデックス
20
128
\ / : * ? " < > | (および空白文字)
PSQL Control Center(PCC)でインデックスを作成する場合、先頭に UK_ を付けてはいけません
PCC 外で UK_ で始まるインデックスを作成した場合、そのインデックスは PCC で編集できません
キー
(外部または主)
20
128
\ / : * ? " < > | (および空白文字)
先頭は文字でなければなりません
同一テーブル内で、外部キーとインデックスに同じ名前を付けることはできません
パスワード
8
128
; ? " '
先頭を空白(空白として使用される文字)にすることはできません
ヌルにすることはできません
[無効な文字]列に挙げられている文字以外の、あらゆる表示可能な文字が指定できます
プロシージャ(ストアド)
30
128
通常の識別子の場合:
` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < , ' > . ? /
文字、数字、およびアンダースコア("_")が有効です
先頭は文字でなければなりません
デリミター付き識別子の場合:
なし
名前を二重引用符で囲む必要があります
テーブル
20
128
\ / : * ? " < > | (および空白文字)
# ##4
無効な文字は、通常とデリミター付きの両方の識別子に適用されます
トリガー
30
128
通常の識別子の場合:
` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < , ' > . ? /
文字、数字、およびアンダースコア("_")が有効です
先頭は文字でなければなりません
デリミター付き識別子の場合:
なし
名前を二重引用符で囲む必要があります
ユーザー
30
128
\ / : * ? " < > | (および空白文字)
MASTER または PUBLIC にすることはできません
ビュー
20
128
通常の識別子の場合:
` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < , ' > . ? /
文字、数字、およびアンダースコア("_")が有効です
先頭は文字でなければなりません
デリミター付き識別子の場合:
なし
名前を二重引用符で囲む必要があります
1 特に示されていない限り、無効な文字は通常の識別子とデリミター付き識別子の両方に適用されます。
2 バージョン 1(V1)メタデータに適用。『ODBC Guide』の SQL 文法のサポートを参照してください。
3 バージョン 2(V2)メタデータに適用。『ODBC Guide』の SQL 文法のサポートを参照してください。
4 テンポラリ テーブルの名前の先頭は # または ## で始まります。このため、# と ## は永続テーブルの名前の先頭文字としては無効です。『SQL Engine Reference』の CREATE (テンポラリ) TABLE を参照してください。
ユニークなスコープ
通常、識別子は一定のスコープ内でユニークである必要があります。つまり、同じ名前を使用する同一タイプのオブジェクトのインスタンスは同一領域内では使用できません。表 2 は、オブジェクト名がどのような領域またはスコープ内でユニークである必要があるかを表します。
表 2 共通識別子のユニーク性の適用範囲
このタイプのオブジェクトの名前
... この範囲内でユニーク
データベース
テーブル
ストアド プロシージャ
その他
データベース
 
 
 
一定のデータベース エンジンによってホストされるすべてのデータベース
テーブル
* 
 
 
 
トリガー、ストアド プロシージャ、ユーザー定義関数
* 
 
 
 
ユーザーまたはグループ
* 
 
 
 
ビュー
* 
 
 
 
制約
* 
 
 
 
 
* 
 
 
インデックス
 
* 
 
外部キーと同じ名前を持つことはできません
キー(外部)
 
* 
 
インデックスと同じ名前を持つことはできません
カーソル
 
 
* 
 
デフォルトのデータベースと現在のデータベース
既存のアプリケーションで、Btrieve ファイルを作成したり開いたりする際にデータベース名を指定していないアプリケーションをサポートするために、PSQL では、トランザクショナル データベース エンジンごとのデフォルト データベースという概念が維持されています。デフォルト データベースは、"DefaultDB" という名前であらかじめ定義されているデータベースです。アプリケーション コードを変更しないで新しいセキュリティ モデルを使うようにするには、Btrieve データ ディレクトリをデフォルト データベースと関連付けてから、それらのディレクトリにあるデータ ファイルへのアクセスを制御するよう、デフォルト データベースでユーザーおよび権限を設定します。
また、データベース エンジンは、クライアント接続ごとの現在のデータベースという概念も理解しています。Btrieve の Login(78)、Create(14)、または Open(0)オペレーションでデータベース名が指定されていない場合、トランザクショナル エンジンは、そのオペレーションは現在のデータベースに関連するものであると見なします。現在のデータベースとは、各クライアントで、一番最近 Login(78)オペレーション(明示的ログイン)が発生したデータベースを指します。クライアント コンピューターが明示的なログイン操作を要求していない場合は、一番最近 Create(14)または Open(0)オペレーション(暗黙ログイン)が発生したデータベースが現在のデータベースとなります。明示的にも暗黙的にもログインが発生していない場合は、前の段落で説明したデフォルト データベースが現在のデータベースとなります。クライアントが明示または暗黙のログインを実行した場合、あるいは最後のファイル ハンドルを閉じることによって DefaultDB が現在のデータベースとなった場合には常に、現在のデータベースが変わる可能性があることに注意してください。各クライアントの現在のデータベースは、ほかのクライアントの動作とは関係ありません。
既存のアプリケーションに新しいセキュリティ モデルを構成する最も簡単な方法は、すべての Btrieve データ ディレクトリをデフォルト データベースと関連付け、このデータベース内で PUBLIC グループの権限を設定することです。PUBLIC グループは、データベースのセキュリティを有効にしたとき、Master ユーザーと共に自動的に作成されます。MicroKernel エンジン セキュリティのクイック スタートを参照してください。
ファイル構造
すべての PSQL データベースは共通のデータ形式を使用します。このファイル形式の共有により、同一データのアクセスにトランザクショナル、リレーショナルなどの異なるアクセス方法を使用することができます。すべてのアクセス方法が機能するために使用するシステムは MicroKernel エンジンと呼ばれます。
各 PSQL データベース テーブルは別個のファイルで、デフォルトで拡張子 MKD を持ちます。ただし、開発者は独自のファイル名拡張子を指定することができます。MicroKernel ファイルはデータとインデックスの両方を持ち、さまざまなタイプのページで構成されます。MicroKernel ファイルは共通のデータ形式でデータを格納します。
各 PSQL データベースには、拡張子 DDF のデータ辞書ファイル一式も含まれます。DDF ファイルにはデータベース スキーマが含まれます。メタデータ バージョン 1 と メタデータ バージョン 2 の DDF は異なるファイル名を使用します。『SQL Engine Reference』のシステム テーブルを参照してください。
MicroKernel エンジンは、キー フィールドは別として、データのスキーマにはまったく無頓着です。ただし、参照整合性の規定または SQL 経由のアクセスではスキーマの知識が必要です。
PSQL データベースの名前とロケーションは dbnames.cfg という名前のバイナリ ファイルに格納されます。PSQL ファイルのデフォルトの保存場所については、『Getting Started With PSQL』の PSQL ファイルはどこにインストールされますか?を参照してください。
PSQL データベースに関連するすべてのファイルはオペレーティング システムから表示させることができます。表 3 は関連するファイルを要約したものです。
表 3 PSQL データベースに関連するファイル
タイプ
説明
データベース名の構成
dbnames.cfg ファイル。PSQL データベースの名前とロケーションを含むバイナリ ファイルです。
データ(共通データ形式)
ファイル名は、リレーショナル データベースの場合デフォルトで、テーブル名.MKD です。データベース テーブルごとに対応する MicroKernel ファイルがあります。トランザクショナル データ ファイルでは、各ファイル名はアプリケーションが指定します。
データ辞書
拡張子が DDF のファイル。『SQL Engine Reference』のシステム テーブルを参照してください。
ファイル サイズ
サイズの制限はファイル バージョンやページ サイズ、および 1 ページあたりのレコード数によって異なるため、次の表にまとめました。
ファイル バージョン 9.5 以上
データ ファイルの最大サイズは 256 GB です。単一ファイルのサイズが 128 GB を超える場合は、9.5 以上のファイル形式を使用する必要があります。
次の表は、ファイルのレコードに圧縮が設定されていないことを前提にしています。レコード圧縮を使用する場合は、1 ページあたりに格納されるレコードがさらに増えることを考慮してください。『PSQL Programmer's Guide』のページ サイズの選択およびファイル サイズの予測を参照してください。
表 4 ファイル バージョン 9.5 以上のファイル サイズおよびページ サイズの比較
1 ページあたりのレコード数
最大ページ数(100 万単位)
各ページ サイズ(バイト)に対するファイル サイズ(GB)
 
 
1,024
2,048
4,096
8,192
16,384
1 - 15
256
256 GB
256 GB
256 GB
256 GB
256 GB
16 - 31
128
128 GB
256 GB
256 GB
256 GB
256 GB
32 - 63
64
64 GB
128 GB
256 GB
256 GB
256 GB
64 - 127
32
32 GB
64 GB
128 GB
256 GB
256 GB
128 - 255
16
16 GB
32 GB
64 GB
128 GB
256 GB
256 - 511
8
N/A1
16 GB
32 GB
64 GB
128 GB
512 - 1023
4
N/A1
N/A1
16 GB
32 GB
64 GB
1024 - 2047
2
N/A1
N/A1
N/A1
16 GB
32 GB
2048 - 4095
1
N/A1
N/A1
N/A1
N/A1
16 GB
1 N/A は「適用外」を意味します。
ファイル バージョン 9.0 以下
データ ファイルの最大サイズは 128 GB です。単一ファイルのサイズが 64 GB を超える場合は、9.0 以上のファイル形式を使用する必要があります。
次の表は、ファイルのレコードに圧縮が設定されていないことを前提にしています。レコード圧縮を使用する場合は、1 ページあたりに格納されるレコードがさらに増えることを考慮してください。『PSQL Programmer's Guide』のページ サイズの選択およびファイル サイズの予測を参照してください。
表 5 ファイル バージョン 9.0 以下のファイル サイズおよびページ サイズの比較
ファイル バージョン
1 ページあたりのレコード数
最大ページ数(100 万単位)
各ページ サイズ(バイト)に対するファイル サイズ(GB)
 
 
 
512
1024
1536
2048
2560
3072
3584
4096
8192
9.0
1 - 15
256
128
128
128
128
128
128
128
128
128
9.0
16 - 31
128
64
128
128
128
128
128
128
128
128
9.0
32 - 63
64
32
64
96
128
128
128
128
128
128
9.0
64 - 127
32
16
32
48
64
80
96
112
128
128
9.0
128 - 255
16
N/A1
16
24
32
40
48
56
64
128
8
任意
16
8
16
24
32
40
48
56
64
N/A1
7
任意
16
8
16
24
32
40
48
56
64
N/A1
6
任意
16
4
4
4
4
4
4
4
4
N/A1
5
任意
16
4
4
4
4
4
4
4
4
N/A1
1 N/A は「適用外」を意味します。
ファイルのセグメント化
デフォルトでは、データ ファイルは、オペレーティング システムのファイル セグメントである 2 GB の限界を超えるごとに自動的に分割されます。[セグメント サイズを 2 GB に制限]設定プロパティを使用すると、ファイルを 2 GB のセグメントに分割するか、セグメント化しない 1 つのファイルとするかを指定することができます。セグメント化されていない大きなファイルを使用する利点は、ディスク I/O が効率的であるということです。このため、パフォーマンスの向上が期待できます。
この設定オプションはデータベース エンジンのパフォーマンス チューニング用プロパティの 1 つです。PCC でエンジンの設定にアクセスするにはおよびセグメント サイズを 2 GB に制限を参照してください。
このプロパティはデフォルトでオンに設定されており、以前のリリースと同様 2 GB の限界でファイルはセグメント化されます。このプロパティをオフに設定すると、ファイルは 2 GB の限界を超えて増大します。設定プロパティの追加情報については、ファイル バージョンの自動アップグレードも参照してください。
セグメントされていないファイルは、お使いのオペレーティング システムによって指定されているファイル サイズの制限を受けます。たとえば、FAT32 ファイル システムで[セグメント サイズを 2 GB に制限]の設定をオフにしてサイズの大きなファイルを作成すると、倍の 4 GB ファイルに拡張されます。以前作成したファイルが既にセグメント化されている場合、そのセグメントはファイル上でそのまま残ります。
ファイル バージョンの自動アップグレード
設定プロパティの[作成ファイルのバージョン]に 9.0 以上が設定されている場合、バージョン 8.x ファイルはそのファイル サイズの限界(64 GB)に達すると自動的にバージョン 9.0 ファイルに変換されます。次の表に、この動作をまとめて示します。
[作成ファイルのバージョン]設定プロパティの設定
[セグメント サイズを 2 GB に制限]設定プロパティの設定
ファイル バージョンの自動アップグレードが起こるファイル サイズ
9(デフォルト)
オン(デフォルト、オプションがチェックされている)
64 GB(バージョン 8.x ファイルの最大サイズ)
9(デフォルト)
オフ(オプションがチェックされていない)
2 GB(バージョン 8.x ファイルのセグメントのサイズ)
たとえば、バージョン 8.x ファイルでサイズが 5 GB の場合は、既に 2 GB 単位のセグメント化が行われています。このファイルは既にセグメント化されているので、そのセグメントはファイルに存在し続けます。このようなファイルはその後もセグメント化が続行され、自動アップグレードが起こるサイズ 64 GB までそのサイズを増大させることができます。この動作は、ファイルが既にセグメント化されているため、設定プロパティがオンまたはオフのどちらであっても同じです。ファイルのサイズが 64 GB を超えると、バージョン 9.0 ファイルの最大許容サイズ 128 GB に達するまでセグメント化が続けられます。
バージョン 8.x ファイルでサイズが 1.5 GB の場合は、そのサイズを 2 GB まで増大させることができます。設定プロパティがオフの場合、このファイル サイズが 2 GB になった時点で自動アップグレードが起こります。このファイルは非セグメント化ファイルとして、そのサイズをバージョン 9.0 ファイルの最大許容サイズ 128 GB まで増大させることができます。設定プロパティをオンに設定すると、2 GB 単位のファイルのセグメント化が続行され、そのサイズを 64 GB のサイズまで増大させることができます。バージョン 8.x ファイル用の最大許容サイズ 64 GB になった時点で、バージョン 9.0 への自動アップグレードが起こります。ファイルのサイズが 64 GB を超えると、バージョン 9.0 ファイルの最大許容サイズ 128 GB に達するまでセグメント化が続けられます。
[作成ファイルのバージョン]オプションは、データベース エンジンのファイル互換性用プロパティの 1 つです。PCC でエンジンの設定にアクセスするにはを参照してください。
メモ: ファイル バージョンの自動アップグレードが動作するのは、8.x ファイル形式から 9.0 ファイル形式というパターンのみです。これ以外のファイル バージョンの組み合わせの場合、この自動アップグレードは動作しません。たとえば、8.x ファイル形式から 9.5 ファイル形式、あるいは 7.x ファイル形式から 9.0 ファイル形式という組み合わせではアップグレードは起こりません。
アクセス方法
PSQL データベースのデータにアクセスする 2 つの主な方法は、トランザクショナルおよびリレーショナル アクセスです。
トランザクショナルでは、アプリケーション プログラムはデータ レコード内を物理的と論理的のどちらの順序に従ってでも自由に移動することができます。トランザクショナル API を使用することで、アプリケーション プログラムは直接制御を備え、開発者はデータの基本構造の知識に基づいてデータ アクセスを最適化することができます。Btrieve は、トランザクショナル データベース エンジンの 1 つです。
リレーショナルとは、データがテーブル、行、列の集まりとして表されるアクセス方法です。リレーショナル モデルは、開発者を基となるデータ構造から切り離し、データを単純な表形式で表します。ODBC はリレーショナル アクセス方法の 1 例です。
単一のアプリケーションが両方のタイプのアクセスを含むこともあります。たとえば、データの追加と変更にはトランザクショナル アクセスを使用し、データの照会およびレポート作成にはリレーショナル アクセスを使用することができます。
アプリケーション プログラムが使用するアクセス方法を知っておく必要があります。これはインストールされる PSQL によって異なります。アクセス方法によって設定が異なります。特定のアクセス方法を最適化するために設定をカスタマイズする必要があります。
利用するアプリケーションが使用するアクセス方法を知っていれば、トラブルシューティングも容易になります。たとえば、アプリケーション プログラムが ODBC 経由でリレーショナル アクセスを使用している場合、データベース管理システムではなく ODBC レベルの問題を解決する必要がある可能性があります。
設定のカスタマイズに関する作業とリファレンスについては、設定リファレンスを参照してください。
クライアント/サーバー通信
MicroKernel エンジンは、ローカルおよびクライアント/サーバーの 2 種類の処理モードをサポートします。ローカル モードでデータベースにアクセスするアプリケーションは、ローカルにあるエンジンにアクセスします。ローカルのエンジンは、ローカルまたはネットワークのハード ディスクの I/O を実行するワークステーションのオペレーティング システムに要求を出します。
クライアント/サーバー モードでは、共有ファイル サーバー上で実行されるサーバー MicroKernel エンジンを使用します。アプリケーション プログラムがクライアント/サーバー モードでデータベース エンジンにアクセスしているときは、リクエスターがリモート エンジンに接続します。このリクエスターは、オペレーティング システムがサポートするネットワーク プロトコルを使用して、トランザクション レベルのリクエストおよびデータ レコードを、アプリケーション プログラムとサーバー エンジン間で受け渡しします。ファイル I/O 機能は、クライアント/サーバー モードのサーバー エンジンによって完全に処理され、ワークステーションには共有データ ファイルのためのオペレーティング システムのハンドルは割り当てられません。データベース操作は、各ワークステーションに代わってサーバー ベースのエンジンによって実行されます。
処理モードは、アプリケーション プログラムそのものではなく、ワークステーションの設定によって決定されることに注意してください。つまり、アプリケーションはローカルとクライアント/サーバー、どちらのデータベース エンジンにもアクセスできます。アプリケーション プログラムは、ローカル モードからクライアント/サーバー モードに切り替える際に再コンパイルする必要はありません。
ワークグループおよびサーバー エンジンはどちらのモードでも動作します。データベース エンジンと同一マシン上のアプリケーションがエンジンにアクセスする場合、ローカル モードで動作します。データベース エンジンと異なるマシン上のアプリケーションがエンジンにアクセスする場合、クライアント/サーバー モードで動作します。
クライアント/サーバーの設定は、PSQL のワークグループおよびサーバー バージョン用にカスタマイズできます。スタンドアロンでもクライアント/サーバーでも、その設定を容易にするための構成の設定プロパティが PSQL Control Center(PCC)に含まれています。
クライアント/サーバー通信およびデータベース エンジンの設定に関する作業とリファレンスについては、設定リファレンスを参照してください。
データベース コード ページ
エンコードは文字セットを表す標準規格です。文字データは、コンピューターがデジタル処理できる標準形式に変換する、つまりエンコードする必要があります。エンコードは、PSQL データベース エンジン(サーバー)と PSQL クライアント アプリケーションとの間で規定する必要があります。互換性のあるエンコードを使用すれば、サーバーとクライアントでデータが正しく変換されます。
エンコードのサポートは、データベース コード ページとクライアント エンコードに分割されています。この 2 種類のエンコードは、別個のものですが相互に関係しています。説明を簡単にするために、データベース コード ページとクライアント エンコードを一緒に説明します。『Getting Started With PSQL』のクライアント用のネットワーク通信の設定を参照してください。
ODBC DSN 作成オプション
ODBC Guide』の DSN のセットアップおよび接続文字列を参照してください。このセクションでは ODBC 接続文字列についても説明しています。
idshosts ファイルの使用
一般的には、アプリケーションは独自のファイルの場所情報を指定します。別の方法として、テキスト ファイル idshosts の情報に基づいてファイル場所のマッピングを指定することができます。
idshosts ファイルは PSQL(IDS)の一部でした。IDS はコア製品から取り除かれましたが、idshosts ファイルの設定は依然として可能です。
作成したアプリケーションでは idshosts によるマッピング機能を使用しないという場合は、[IDS の使用]設定をオフにします。あるいは、既に idshosts を使用していたり、この代替方法を使用してファイルの場所をマップしたいと考えている場合には、[IDS の使用]設定をオンにします。IDS の使用を参照してください。
idshosts ファイルを使用する場合は、ファイルにアクセスして内容を読み取る時間が必要となるため、パフォーマンスが低下することに注意してください。
idshosts ファイルは、Windows、Linux、または OS X クライアント リクエスターでのみ使用できます。クライアントは Windows、Linux、または OS X 上の PSQL サーバーと通信できます。
メモ: IDS の使用]をオンに設定するには、PSQL 8.5 以降が必要です。リクエスターはデータベース URI を使用して IDS 情報を表します。データベース URI は PSQL 8.5 で追加されました。開発者リファレンス『PSQL Programmer's Guide』のデータベース URI を参照してください。

IDS の使用]にオンを設定した場合、[リモート MicroKernel エンジンの使用]もオンに設定する必要があります。[リモート MicroKernel エンジンの使用]はデフォルトでオンです。

IDS の使用およびリモート MicroKernel エンジンの使用を参照してください。
idshosts エントリの形式
idshosts ファイル内のエントリの形式については、ファイル自体のコメントを参照してください。コメントにはマッピングの例も提供されています。デフォルトで、Windows プラットフォームの場合には、idshosts ファイルはデータベース クライアントのインストール ディレクトリ下の \bin ディレクトリにインストールされます。Linux および OS X の場合には、idshosts ファイルはデータベース クライアントのインストール ディレクトリ下の \etc ディレクトリにインストールされます(例:/user/local/psql/etc)。