|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/ref/declare.sgml,v 1.46 2009/04/1017:56:21 tgl Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/ref/declare.sgml,v 1.47 2009/06/1019:21:37 tgl Exp $ |
3 | 3 | PostgreSQL documentation |
4 | 4 | --> |
5 | 5 |
|
@@ -228,6 +228,20 @@ DECLARE <replaceable class="parameter">name</replaceable> [ BINARY ] [ INSENSITI |
228 | 228 | <literal>SCROLL</literal> may not be specified in this case. |
229 | 229 | </para> |
230 | 230 |
|
| 231 | + <caution> |
| 232 | + <para> |
| 233 | + Scrollable and <literal>WITH HOLD</literal> cursors may give unexpected |
| 234 | + results if they invoke any volatile functions (see <xref |
| 235 | + linkend="xfunc-volatility">). When a previously fetched row is |
| 236 | + re-fetched, the functions might be re-executed, perhaps leading to |
| 237 | + results different from the first time. One workaround for such cases |
| 238 | + is to declare the cursor <literal>WITH HOLD</literal> and commit the |
| 239 | + transaction before reading any rows from it. This will force the |
| 240 | + entire output of the cursor to be materialized in temporary storage, |
| 241 | + so that volatile functions are executed exactly once for each row. |
| 242 | + </para> |
| 243 | + </caution> |
| 244 | + |
231 | 245 | <para> |
232 | 246 | If the cursor's query includes <literal>FOR UPDATE</> or <literal>FOR |
233 | 247 | SHARE</>, then returned rows are locked at the time they are first |
|