システム情報関数

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 第 9章関数と演算子 | 早送り | 次のページ

# 9.23. システム情報関数

表9-47に、セッションおよびシステムの情報を抽出する関数を示します。

本節でリストされている関数のほかに、同様にシステム情報を提供する統計システムに関連した数多くの関数があります。

表 9-47. セッション情報関数

名前 | 戻り型 | 説明
--- | --- | ---
``current_catalog`` | `name` | （SQL標準で"カタログ"と呼ばれる）現在のデータベースの名前
``current_database`()` | `name` | 現在のデータベースの名前
``current_schema`[()]` | `name` | 現在のスキーマの名前
``current_schemas`(`boolean`)` | `name[]` | オプションで暗黙的なスキーマも含む、検索パス内のスキーマの名前
``current_user`` | `name` | 現在の実行コンテキストのユーザ名
``current_query`` | `text` | クライアントから提示された、現在実行中問い合わせのテキスト（複数の文を含むことあり）
``pg_backend_pid`()` | `int` | 現在のセッションに結びついたサーバプロセスのプロセスID
``inet_client_addr`()` | `inet` | リモート接続のアドレス
``inet_client_port`()` | `int` | リモート接続のポート
``inet_server_addr`()` | `inet` | ローカル接続のアドレス
``inet_server_port`()` | `int` | ローカル接続のポート
``pg_my_temp_schema`()` | `oid` | セッションの一時スキーマのOID。もしなければ０
``pg_is_other_temp_schema`(`oid`)` | `boolean` | スキーマが他のセッションの一時スキーマかどうか？
``pg_postmaster_start_time`()` | `timestamp with time zone` | サーバの起動時刻
``pg_conf_load_time`()` | `timestamp with time zone` | 設定を読み込んだ時刻
``session_user`` | `name` | セッションのユーザ名
``user`` | `name` | `current_user`と等価
``version`()` | `text` | PostgreSQLバージョン情報

`session_user`は、通常、現在のデータベース接続を初期化したユーザです。しかし、スーパユーザはこの設定をSET SESSION AUTHORIZATIONを使用して変更することができます。`current_user`は、権限の検査に適用されるユーザ識別子です。通常はセッションユーザと同じですが、SET ROLEを使用して変更可能です。`SECURITY DEFINER`属性を持つ関数の実行中にも変更します。Unix用語で言うと、セッションユーザは"実ユーザ"で、現在のユーザは"実効ユーザ"です。

> 注意: `current_catalog`,、`current_schema`、`current_user`、`session_user`、および`user`はSQLにおいて特殊な構文上の地位を持っており、括弧を付けずに呼び出さなければなりません（`current_schema`の場合、PostgreSQLでは省略可能）。

`current_schema`関数は、検索パスの最初にあるスキーマ名（もしくは、検索パスが空の場合はNULL値）を返します。これは、対象スキーマを指定せずに作成された、任意のテーブルまたは他の名前付きオブジェクトに使用されるスキーマです。また、`current_schemas(boolean)` は、検索パスに存在する全てのスキーマ名の配列を返します。 booleanオプションにより、`pg_catalog`のような暗黙的に含まれているシステムスキーマを、結果の検索パスに含めるかどうかを指定します。

> 注意: 検索パスは、実行時の設定で変更することができます。使用するコマンドは以下の通りです。

>     SET search_path TO schema [, schema, ...]

`inet_client_addr`は現在のクライアントのIPアドレスを返し、`inet_client_port`はそのポート番号を返します。`inet_server_addr`は、現在の接続を受け付けたサーバのIPアドレスを返し、`inet_server_port`はそのポート番号を返します。これら全ての関数は接続がUnix-domain socket経由の場合NULLを返します。

`pg_my_temp_schema`は、現在のセッションの一時スキーマのOIDを返します。もし（どんな一時テーブルも作成していないので）存在しなければゼロを返します。`pg_is_other_temp_schema`は、指定したOIDが他のセッションの一時スキーマのOIDであれば、真を返します。（例えば、他のセッションの一時テーブルをカタログ表示から除外したい場合などで有用です。）

`pg_postmaster_start_time`はサーバが起動した時の`timestamp with time zone`を返します。

`pg_conf_load_time`はサーバの設定ファイルが最後に読み込まれた時の`timestamp with time zone`を返します。 （現在のセッションがその時点で稼働していた場合、これはセッション自体が設定ファイルを読み込んだ時刻となります。 このためこの読み取った結果は多少他のセッションと異なります。 この他の場合は、postmasterプロセスが設定ファイルを再読み込みした時刻となります。）

`version`関数はPostgreSQLサーバのバージョンを記述した文字列を返します。

表9-48に列挙した関数を使用して、ユーザはオブジェクトのアクセス権限をプログラムから問い合わせることができます。権限についての詳細は、項5.6を参照してください。

表 9-48. アクセス権限照会関数

名前 | 戻り型 | 説明
--- | --- | ---
``has_any_column_privilege`(`user`, `table`, `privilege`)` | `boolean` | ユーザがテーブルのどの列に対しても権限を所有しているか
``has_any_column_privilege`(`table`, `privilege`)` | `boolean` | 現在のユーザがテーブルのどの列に対しても権限を所有しているか
``has_column_privilege`(`user`, `table`, `column`, `privilege`)` | `boolean` | ユーザに列に対する権限があるか
``has_column_privilege`(`table`, `column`, `privilege`)` | `boolean` | 現在のユーザに列に対する権限があるか
``has_database_privilege`(`user`, `database`, `privilege`)` | `boolean` | ユーザにデータベースに対する権限があるのか
``has_database_privilege`(`database`, `privilege`)` | `boolean` | 現在のユーザにデータベースに対する権限があるのか
``has_foreign_data_wrapper_privilege`(`user`, `fdw`, `privilege`)` | `boolean` | ユーザに外部データラッパに対する権限があるのか
``has_foreign_data_wrapper_privilege`(`fdw`, `privilege`)` | `boolean` | 現在のユーザに外部データラッパに対する権限があるのか
``has_function_privilege`(`user`, `function`, `privilege`)` | `boolean` | ユーザに関数に対する権限があるのか
``has_function_privilege`(`function`, `privilege`)` | `boolean` | 現在のユーザに関数に対する権限があるのか
``has_language_privilege`(`user`, `language`, `privilege`)` | `boolean` | ユーザに言語に対する権限があるのか
``has_language_privilege`(`language`, `privilege`)` | `boolean` | 現在のユーザに言語に対する権限があるのか
``has_schema_privilege`(`user`, `schema`, `privilege`)` | `boolean` | ユーザにスキーマに対する権限があるのか
``has_schema_privilege`(`schema`, `privilege`)` | `boolean` | 現在のユーザにスキーマに対する権限があるのか
``has_server_privilege`(`user`, `server`, `privilege`)` | `boolean` | ユーザに外部サーバに対する権限があるのか
``has_server_privilege`(`server`, `privilege`)` | `boolean` | 現在のユーザに外部サーバに対する権限があるのか
``has_table_privilege`(`user`, `table`, `privilege`)` | `boolean` | ユーザにテーブルに対する権限があるのか
``has_table_privilege`(`table`, `privilege`)` | `boolean` | 現在のユーザにテーブルに対する権限があるのか
``has_tablespace_privilege`(`user`, `tablespace`, `privilege`)` | `boolean` | ユーザにテーブル空間に対する権限があるのか
``has_tablespace_privilege`(`tablespace`, `privilege`)` | `boolean` | 現愛のユーザにテーブル空間に対する権限があるのか
``pg_has_role`(`user`, `role`, `privilege`)` | `boolean` | ユーザにロールに対する権限があるのか
``pg_has_role`(`role`, `privilege`)` | `boolean` | 現在のユーザにロールに対する権限があるのか

`has_table_privilege`はあるユーザが特定の方法でテーブルにアクセス可能かどうかを検査します。ユーザは名前、またはOIDで指定できます。（従って、実際には`has_table_privilege`の６つの変形があり、引数の数と型で区別されます。）名前を指定する場合、必要であればスキーマ権限で指定できます。目的とするアクセス権限の型はテキスト文字列で指定され、それは、`SELECT`、`INSERT`、 `UPDATE`, `DELETE`, `TRUNCATE`, `REFERENCES`、または`TRIGGER`の内の１つで評価されます。オプションとして、権限がGRANTオプションにより付与されているかどうかの権限の検査するため、`WITH GRANT OPTION`を負荷することができます。更に、複数の権限型はコンマで分割してたリスト可能です。この場合、結果はリストされた権限の１つでも存在すれば`真`となります。（権限文字列が有効でない場合、追加の空白を権限名の中を除き、間に挿入できます。）例を示します。

    SELECT has_table_privilege('myschema.mytable', 'select');
    SELECT has_table_privilege('joe', 'mytable', 'INSERT, SELECT WITH GRANT OPTION');

`has_any_column_privilege`はあるユーザが特定の方法でテーブルのどんな列にもアクセス可能かどうかを検査します。 可能な引数は`has_table_privilege`に対するものと類似していますが、`SELECT`、`INSERT`、`UPDATE`、または`REFERENCES`のいくつかの組み合わせで目的とする権限型が評価される点を除きます。テーブル階層におけるこれらの権限を所有することは、テーブルのそれぞれの列に対し暗黙的にそれら権限を与えることに注意してください。従って、`has_table_privilege`が同一の引数を対象とする場合、`has_any_column_privilege`は常に`真`を返します。しかし、少なくとも一つの列に対し権限の列階層許可があれば、`has_any_column_privilege`も成功します。

`has_column_privilege`はあるユーザが特定の方法でテーブルのある列にもアクセス可能かどうかを検査します。 可能な引数は、列が追加的に名前または属性番号のいずれかで指定される点を加えれば、`has_table_privilege`と類似しています。目的と知るアクセス権限型は、`SELECT`、`INSERT`、`UPDATE`、または`REFERENCES`のいくつかの組み合わせで評価されなければなりません。テーブル階層におけるこれらの権限を所有することは、テーブルのそれぞれの列に対し暗黙的にそれら権限を与えることに注意してください。

`has_database_privilege`関数は、あるユーザが特定の方法でデータベースにアクセス可能かどうかを検査します。 可能な引数は、`has_table_privilege`に類似しています。対象とするアクセス権限の種類は、`CREATE`、`CONNECT`、`TEMPORARY`、または`TEMP`（`TEMPORARY`と同じ）のいくつかの組み合わせでで評価する必要があります。

`has_function_privilege`関数は、あるユーザが特定の方法で関数にアクセス可能かどうかを検査します。 引数として取り得るものは`has_table_privilege`と同じです。関数をOIDではなくテキスト文字列で指定した場合、`regprocedure` データ型（項8.16を参照）と同じ入力が可能です。対象とするアクセス権限の種類は、現在`EXECUTE`で評価する必要があります。以下に例を示します。

    SELECT has_function_privilege('joeuser', 'myfunc(int, text)', 'execute');

`has_foreign_data_wrapper_privilege`関数は、あるユーザが特定の方法で外部データラッパーにアクセス可能かどうかを検査します。 引数として取り得るものは`has_table_privilege`と同じです。対象とするアクセス権限の種類は`USAGE`で評価する必要があります。

`has_language_privilege`関数は、あるユーザが特定の方法で手続き言語にアクセス可能かどうかを検査します。 可能な引数は、`has_table_privilege`に類似しています。対象とするアクセス権限の種類は、現在`USAGE`で評価する必要があります

`has_schema_privilege`関数は、あるユーザが特定の方法でスキーマにアクセス可能かどうかを検査します。 可能な引数は、`has_table_privilege`に類似しています。対象とするアクセス権限の種類は、`CREATE`もしくは`USAGE`の何らかの組み合わせで評価する必要があります。

`has_server_privilege`はユーザが特定の方法で外部サーバにアクセスできるかどうかを検査します。 可能な引数は`has_table_privilege`に類似しています。対象とするアクセス権限は`USAGE`で評価する必要があります。

`has_tablespace_privilege`関数は、あるユーザが特定の方法でテーブル空間にアクセス可能かどうかを検査します。 可能な引数は、`has_table_privilege`に類似しています。対象とするアクセス権限の種類は、`CREATE`で評価する必要があります。

`pg_has_role`は、ユーザが特定の方法でロールにアクセスできるかどうかを検査します。 取り得る引数については`has_table_privilege`と類似しています。対象とするアクセス権限の種類は、 `MEMBER`、`USAGE`の組み合わせで評価する必要があります。`MEMBER`は、ロールの直接または間接メンバ資格（つまり、`SET ROLE`を行う権限）を表します。一方、`USAGE`は、そのロール権限が`SET ROLE`をしなくてもすぐに利用できることを表します。

表9-49に、特定のオブジェクトが、現行スキーマの検索パスにおいて可視かどうかを判別する関数を示します。例えば、あるテーブルを含むスキーマが検索パス内に存在し、検索パス内の前方に同じ名前のテーブルがない場合、そのテーブルは可視であると言います。つまり、これは、テーブルが明示的なスキーマ修飾なしで名前によって参照可能であるということです。全ての可視テーブルの名前を列挙するには以下のようにします。

    SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);

表 9-49. スキーマ可視性照会関数

名前 | 戻り型 | 説明
--- | --- | ---
``pg_conversion_is_visible`(`conversion_oid`)` | `boolean` | 変換が検索パスにおいて可視かどうか
``pg_function_is_visible`(`function_oid`)` | `boolean` | 関数が検索パスにおいて可視であるか
``pg_operator_is_visible`(`operator_oid`)` | `boolean` | 演算子が検索パスにおいて可視であるか
``pg_opclass_is_visible`(`opclass_oid`)` | `boolean` | 演算子クラスが検索パスにおいて可視であるか
``pg_table_is_visible`(`table_oid`)` | `boolean` | テーブルが検索パスにおいて可視かどうか
``pg_ts_config_is_visible`(`config_oid`)` | `boolean` | テキスト検索構成が検索パスにおいて可視かどうか
``pg_ts_dict_is_visible`(`dict_oid`)` | `boolean` | テキスト検索辞書が検索パスにおいて可視かどうか
``pg_ts_parser_is_visible`(`parser_oid`)` | `boolean` | テキスト検索パーサが検索パスにおいて可視かどうか
``pg_ts_template_is_visible`(`template_oid`)` | `boolean` | テキスト検索テンプレートが検索パスにおいて可視かどうか
``pg_type_is_visible`(`type_oid`)` | `boolean` | 型（またはドメイン）が検索パスにおいて可視かどうか

それぞれの関数はデータベースオブジェクトの１つの型に対して可視性の検査を行います。`pg_table_is_visible`がビュー、インデックス、シーケンスに対しても使用できること、`pg_type_is_visible`がドメインに対しても使用できることに注意してください。関数および演算子では、パスの前方に同じ名前かつ同じ引数のデータ型を持つオブジェクトが存在しなければ、検索パス内のオブジェクトは可視です。演算子クラスでは、名前と関連するインデックスアクセスメソッドが考慮されます。

これらの関数は全て、検査するオブジェクトを識別するために、オブジェクトのOIDを必要とします。オブジェクトを名前でテストする場合、OID別名型（`regclass`、`regtype`、`regprocedure`、`regoperator`、`regconfig`、または`regdictionary`）を使用すると便利です。例えば、以下のようにします。

    SELECT pg_type_is_visible('myschema.widget'::regtype);

ただし、このようなやり方でスキーマ修飾されていない型名をテストしても、あまり意味がないことに注意してください。名前が認識されれば、それは必ず可視ということになります。

表9-50に、システムカタログから情報を抽出する関数を列挙します。

表 9-50. システムカタログ情報関数

名前 | 戻り型 | 説明
--- | --- | ---
``format_type`(`type_oid`, `typemod`)` | `text` | データ型のSQL名の取得
``pg_get_keywords`()` | `setof record` | SQLキーワードとそれらの種類のリストを取得
``pg_get_constraintdef`(`constraint_oid`)` | `text` | get definition of a constraint
``pg_get_constraintdef`(`constraint_oid`, `pretty_bool`)` | `text` | 制約の定義を取得
``pg_get_expr`(`expr_text`, `relation_oid`)` | `text` | 式中のいかなるVarも、２番目のパラメータによって指定されるリレーションを参照すると仮定して、式の内部形式を逆コンパイル
``pg_get_expr`(`expr_text`, `relation_oid`, `pretty_bool`)` | `text` | 式中のいかなるVarも、２番目のパラメータによって指定されるリレーションを参照すると仮定して、式の内部形式を逆コンパイル
``pg_get_functiondef`(`func_oid`)` | `text` | 関数定義の取得
``pg_get_function_arguments`(`func_oid`)` | `text` | 関数定義（デフォルト値付き）の引数リストを取得
``pg_get_function_identity_arguments`(`func_oid`)` | `text` | 関数（デフォルト値付き）特定の引数リストを取得
``pg_get_function_result`(`func_oid`)` | `text` | 関数に対する`RETURNS`句の取得
``pg_get_indexdef`(`index_oid`)` | `text` | インデックスに対する`CREATE INDEX`コマンドの取得
``pg_get_indexdef`(`index_oid`, `column_no`, `pretty_bool`)` | `text` | インデックスに対する`CREATE INDEX`コマンドの取得、または`column_no`が非ゼロの場合は、１つのインデックス列のみの定義の取得
``pg_get_ruledef`(`rule_oid`)` | `text` | ルールに対する`CREATE RULE`コマンドを取得
``pg_get_ruledef`(`rule_oid`, `pretty_bool`)` | `text` | ルールに対する`CREATE RULE`コマンドを取得
``pg_get_serial_sequence`(`table_name`, `column_name`)` | `text` | `serial`または`bigserial`列が使用するシーケンス名の取得
`pg_get_triggerdef`(`trigger_oid`) | `text` | トリガに対する`CREATE [ CONSTRAINT ] TRIGGER`コマンドの取得
``pg_get_userbyid`(`role_oid`)` | `name` | 与えられたOIDでロール名を取得
``pg_get_viewdef`(`view_name`)` | `text` | ビューに対する現在の`SELECT`コマンドを取得（廃止予定）
``pg_get_viewdef`(`view_name`, `pretty_bool`)` | `text` | ビューに対する現在の`SELECT`コマンドを取得（廃止予定）
``pg_get_viewdef`(`view_oid`)` | `text` | ビューに対する現在の`SELECT`コマンドを取得
``pg_get_viewdef`(`view_oid`, `pretty_bool`)` | `text` | ビューに対する現在の`SELECT`コマンドを取得
``pg_tablespace_databases`(`tablespace_oid`)` | `setof oid` | テーブル空間内にオブジェクトを所有するデータベースOID集合を取得
``pg_typeof`(`any`)` | `regtype` | 指定した値のデータ型を取得

関数`format_type`は、自身の型OIDと場合により型修飾子によって特定されるデータ型のSQL名を返します。特定の修飾子が既知でなければ型修飾子にNULLを渡します。

関数`pg_get_keywords`は、サーバが認識したSQLキーワードを記述するレコード一式を返します。`word`列にはキーワードが含まれます。The `catcode`列は種類コードを含みます。それらは、予約されていないを表わす`U`、列名の`C`、関数名型の`T`、または予約語であることの`R`、のいずれかです。`catdesc`列は種類を記述する現地語化された可能性のある文字列を含みます。

`pg_get_constraintdef`、 `pg_get_indexdef`、`pg_get_ruledef`、 および `pg_get_triggerdef`それぞれは、対応する制約、インデックス、ルール、もしくはトリガに対するコマンド作成を再構築します。（これはコマンドのオリジナルテキストではなく、逆コンパイルされた再構築であることに注意してください。）`pg_get_expr`は、列のデフォルト値のような個々の式の内部形式を逆コンパイルします。システムカタログの内容を試験するときに便利です。 もしも式がVarを含んでいるとすれば、２番目のパラメータとして参照する関連（リレーション）のOIDを指定します。もしVarがないと期待されればゼロで充分です。 `pg_get_viewdef` はビューを定義する`SELECT`問い合わせを再構築します。これらの関数のほとんどは２つの異形があり、そのうちの１つはオプションとして結果を"pretty print"（訳注："見やすく表示"）します。pretty printされた書式はより読みやすい半面、デフォルトの書式の方が今後のバージョンのPostgreSQLでも同様に解釈することができそうです。ダンプを目的とする場合は、見やすく表示する出力を使用しないでください。見やすい表示用のパラメータに`false`を渡すことで、このパラメータをまったく持たない種類の結果と同一の結果を生成します

`pg_get_functiondef`は、ある関数の`CREATE OR REPLACE FUNCTION`文全てを返します。`pg_get_function_arguments`は、`CREATE FUNCTION`の中に出現しなければならない形式で、引数リストを返します。`pg_get_function_result`は同様、その関数の適切な`RETURNS`句を返します。`pg_get_function_identity_arguments`は、インスタンスに対し、`ALTER FUNCTION`の中に出現しなければならない形式で、ある関数を特定するのに必要な引数リストを返します。この形式はデフォルト値を省略します。

`pg_get_serial_sequence`は、列に関連したシーケンスの名前を返します。もし、列に関連したシーケンスが存在しなければ、NULLを返します。最初の入力パラメータはテーブル名です。スキーマを付けることもできます。２番目のパラメータは列名です。最初のパラメータは普通スキーマとテーブルですので、二重引用符付の識別子としては解釈されません。つまり、デフォルトで小文字に変換されます。一方２番目のパラメータは単なる列名であり、二重引用符付として解釈され、その大文字小文字は保持されます。この関数は、シーケンス関数に渡すことができるよう適切な書式で値を返します（項9.15を参照）。この関連付けは`ALTER SEQUENCE OWNED BY`により変更、削除することができます。（この関数はおそらく`pg_get_owned_sequence`から呼び出されるはずです。その現在の名前は、`serial`や `bigserial`列で実際に入力されたものが反映されます。）

`pg_get_userbyid`はそのOIDで与えられたロールの名前を抽出します。

`pg_tablespace_databases`によりテーブル空間の使用状況を確認することができます。これは、そのテーブル空間内に格納されたオブジェクトを持つデータベースのOIDの集合を返します。この関数が何らかの行を返した場合、このテーブル空間は空ではなく、そのため、削除することができませんテーブル空間内に格納された特定のオブジェクトを表示するためには、`pg_tablespace_databases`で識別されたデータベースに接続し、その`pg_class`カタログに問い合わせを行う必要があります。

`pg_typeof`は、OIDに渡される値のデータ型のOIDを返します。これはトラブル解決作業、または動的にSQL問い合わせを生成するのに便利です。この関数は、OIDエイリアス型である`regtype`を返すものとして宣言されます（項8.16を参照）。つまり、比較目的でのOIDと同一ですが、型名として表示されます。以下に例をあげます。

    SELECT pg_typeof(33);

     pg_typeof
    -----------
     integer
    (1 row)

    SELECT typlen FROM pg_type WHERE oid = pg_typeof(33);
     typlen
    --------
          4
    (1 row)

表9-51に示される関数は、COMMENTコマンドによって以前に保存されたコメントを抽出します。指定されたパラメータに対するコメントが検出されない場合、NULL値が返されます。

表 9-51. コメント情報関数

名前 | 戻り型 | 説明
--- | --- | ---
``col_description`(`table_oid`, `column_number`)` | `text` | テーブル列のコメントを取得
``obj_description`(`object_oid`, `catalog_name`)` | `text` | データベースオブジェクトのコメントを取得
``obj_description`(`object_oid`)` | `text` | データベースオブジェクトのコメントを取得（廃止予定）
``shobj_description`(`object_oid`, `catalog_name`)` | `text` | 共有データベースオブジェクトのコメントを取得

`col_description()`関数は、テーブルのOIDとその列番号で指定されるテーブルの列のコメントを返します。`obj_description()`関数は、テーブル列自体がOIDを所有していませんので、テーブル列に対して使用することはできません。

`obj_description()`関数の２つのパラメータを取る形式はそのOIDと保有しているシステムカタログの名前で指定されたデータベースオブジェクトのコメントを返します。例えば、`obj_description(123456,'pg_class')`はOID 123456を持つテーブルのコメントを抽出します。`obj_description()`関数の単一パラメータ形式はオブジェクトのOIDのみ必要とします。異なったシステムカタログに渡ってOIDが一意である保証はないことから廃止予定です。従って、間違ったコメントが返ることがあります。

`shobj_description`は、共有オブジェクトのコメント取得のために使用されることを除いて、`obj_description`と同じように使用されます。一部のシステムカタログは、各クラスタ内のデータベース全体に対して大域的です。これらのコメントも同様に大域的に格納されます。

表9-52で示される関数はサーバトランザクション情報をエクスポートできる形式で提供します。これら関数の主な使用目的は２つのスナップショット間でどちらのトランザクションがコミットされたのかを特定するためです。

表 9-52. トランザクションIDとスナップショット

名前 | 戻り型 | 説明
--- | --- | ---
``txid_current`()` | `bigint` | 現在のトランザクションIDの取得
``txid_current_snapshot`()` | `txid_snapshot` | 現在のスナップショットの取得
``txid_snapshot_xmin`(`txid_snapshot`)` | `bigint` | スナップショットのxminの取得
``txid_snapshot_xmax`(`txid_snapshot`)` | `bigint` | スナップショットのxmaxの取得
``txid_snapshot_xip`(`txid_snapshot`)` | `setof bigint` | スナップショットにある進行中のトランザクションIDの取得
``txid_visible_in_snapshot`(`bigint`, `txid_snapshot`)` | `boolean` | スナップショットにあるトランザクションIDは可視か？（減算識別子と一緒に使用しないこと）

内部トランザクションID型（`xid`）は32ビット幅あるので４０億トランザクション毎ラップします。とは言っても、これらの関数は"epoch"カウンタにより64ビット形式にエクスポートするため、インストレーションの生涯にわたってラップしません。これらの関数で使用されるデータ型、`txid_snapshot`はある時間特有時のトランザクションIDの可視化に関する情報を格納します。構成要素は表9-53に記載されています。

表 9-53. スナップショット構成要素

名前 | 説明
--- | ---
`xmin` | いまだ使用中の最先として出現したトランザクションID（txid）。全ての最も早期のトランザクションはコミットされ、可視化となるか、またはロールバックされ消滅するのいずれか。
`xmax` | 最初のまだ割り当てられていないtxid。これと等しいかより大きい全てのtxidはスナップショットの時点で未開始。従って不可視。
`xip_list` | スナップショット時の使用中のtxid。リストは`xmin`と`xmax`間にのみ使用中のtxidを含む。`xmax`より高位の使用中のtxidが存在することもある。 `xmin <= txid < xmax`であり、このリストにないtxidはスナップショット時に既に完了している。従い、コミット状態で可視か消滅かのいづれか。リストには副トランザクションのtxidは含まれない。

`txid_snapshot`のテキスト表現は``xmin`:`xmax`:`xip_list``。例えば、`10:20:10,14,15`は`xmin=10, xmax=20, xip_list=10, 14, 15`を指す。

前のページ | ホーム | 次のページ
集合を返す関数 | 上に戻る | システム管理関数