Re: key = currval('tab_key_seq') choses SEQSCAN?!

On Feb 25, 2004, at 8:02 PM, Tom Lane wrote:

> Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)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(at)postgresql(dot)org)