Brandon Craig Rhodes <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED])
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
