Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 661b3e7

Browse files
committed
Add a warning about possible strange behavior of volatile functions
in cursors. This has always been the case, but given the lack of user complaints about it, I'm not going to bother back-patching this.
1 parent 61dd418 commit 661b3e7

File tree

1 file changed

+15
-1
lines changed

1 file changed

+15
-1
lines changed

doc/src/sgml/ref/declare.sgml

+15-1
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/declare.sgml,v 1.46 2009/04/10 17:56:21 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/declare.sgml,v 1.47 2009/06/10 19:21:37 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -228,6 +228,20 @@ DECLARE <replaceable class="parameter">name</replaceable> [ BINARY ] [ INSENSITI
228228
<literal>SCROLL</literal> may not be specified in this case.
229229
</para>
230230

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+
231245
<para>
232246
If the cursor's query includes <literal>FOR UPDATE</> or <literal>FOR
233247
SHARE</>, then returned rows are locked at the time they are first

0 commit comments

Comments
 (0)