SPI_cursor_parse

PostgreSQL 16.0文書
		47.1. インタフェース関数	誤訳等の報告
前へ	上へ	SPI_cursor_parse_open	次へ

SPI_cursor_parse_open

SPI_cursor_parse_open <refpurpose>set up a cursor using a query string and parameters</refpurpose> — 問い合わせ文字列とパラメータを使ってカーソルを設定する

概要

Portal SPI_cursor_parse_open(const char *name,
                             const char *command,
                             const SPIParseOpenOptions * options)

説明

<title>Description</title>

<function>SPI_cursor_parse_open</function> sets up a cursor (internally, a portal) that will execute the specified query string. This is comparable to <function>SPI_prepare_cursor</function> followed by <function>SPI_cursor_open_with_paramlist</function>, except that parameter references within the query string are handled entirely by supplying a <literal>ParamListInfo</literal> object. SPI_cursor_parse_openは特定の問い合わせ文字列を実行するカーソル（内部的にはポータル）を設定します。これは、問い合わせ文字列内のパラメータ参照がParamListInfoを与えることで完全に取り扱われることを除いて、SPI_prepare_cursorに続けてSPI_cursor_open_with_paramlistを実行するのと似ています。

For one-time query execution, this function should be preferred over <function>SPI_prepare_cursor</function> followed by <function>SPI_cursor_open_with_paramlist</function>. If the same command is to be executed with many different parameters, either method might be faster, depending on the cost of re-planning versus the benefit of custom plans. 一度限りの問い合わせの実行に対しては、この関数はSPI_prepare_cursorに続いてSPI_cursor_open_with_paramlistを実行するよりも好ましいです。同じコマンドが多くの異なるパラメータで実行されるのなら、再計画のコストとカスタム計画の利益に依存してどちらかの方法がより速いでしょう。

The <parameter>options->params</parameter> object should normally mark each parameter with the <literal>PARAM_FLAG_CONST</literal> flag, since a one-shot plan is always used for the query. その問い合わせに対しては一度限りの計画が必ず使われますので、options->paramsオブジェクトは通常各パラメータにPARAM_FLAG_CONSTフラグをつけるべきです。

The passed-in parameter data will be copied into the cursor's portal, so it can be freed while the cursor still exists. 渡されてきたパラメータデータはカーソルのポータルにコピーされますので、カーソルが存在している間に解放できます。

引数

<title>Arguments</title>

const char * name: name for portal, or <symbol>NULL</symbol> to let the system select a name ポータルの名前、あるいはシステムに名前を決定させる場合はNULL
const char * command: command string コマンド文字列
const SPIParseOpenOptions * options: struct containing optional arguments オプションの引数を含む構造体

Callers should always zero out the entire <parameter>options</parameter> struct, then fill whichever fields they want to set. This ensures forward compatibility of code, since any fields that are added to the struct in future will be defined to behave backwards-compatibly if they are zero. The currently available <parameter>options</parameter> fields are: 呼び出し元は、必ずoptions構造体全体をゼロクリアしてから、設定したいフィールドを埋めるべきです。構造体に将来追加されるフィールドは、ゼロであれば後方互換性があるように振る舞うよう定義されますので、これはコードの将来の互換性を確実にします。現在利用可能なoptionsフィールドは以下の通りです。

ParamListInfo params: data structure containing query parameter types and values; NULL if none 問い合わせパラメータの型と値を含むデータ構造。なければNULL
int cursorOptions: integer bit mask of cursor options; zero produces default behavior カーソルオプションの整数ビットマスク。ゼロの場合はデフォルトの動作
bool read_only: <para><literal>true</literal> for read-only execution</para>
読み取りのみの実行の場合true

戻り値

<title>Return Value</title>

Pointer to portal containing the cursor. Note there is no error return convention; any error will be reported via <function>elog</function>. カーソルを含んだポータルへのポインタ。エラーを返す規約がないことに注意してください。すべてのエラーはelogで報告されます。

前へ	上へ	次へ
SPI_cursor_open_with_paramlist	ホーム	SPI_cursor_find