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
)
<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. 渡されてきたパラメータデータはカーソルのポータルにコピーされますので、カーソルが存在している間に解放できます。
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
読み取りのみの実行の場合true
Pointer to portal containing the cursor. Note there is no error
return convention; any error will be reported via <function>elog</function>.
カーソルを含んだポータルへのポインタ。
エラーを返す規約がないことに注意してください。
すべてのエラーはelog
で報告されます。