On Feb 25, 2004, at 8:02 PM, Tom Lane wrote:
> Brandon Craig Rhodes <brandon@oit.gatech.edu> writes:
>> But this same table suddenly becomes unwilling to use an index scan if
>> the target value is the result of the currval() function:
>
> currval() is considered a volatile function, therefore it is unsafe to
> use in an indexscan constraint.
I suppose this is obvious, but it's volatile because *other* backends
can change it while the current transaction is still in progress?
eric
>
> The subselect hack mentioned nearby fools the planner ... at the
> moment.
> I wouldn't guarantee that it will work indefinitely. A better solution
> is to wrap currval() in a function that you lyingly claim is stable.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to
> majordomo@postgresql.org)
