"Tom Lane" <[EMAIL PROTECTED]> writes: > We have so far managed to avoid any really strong dependencies on the > requirement of index-function immutability --- your queries may not work > very well if the function isn't immutable, but you are not at risk of > system-level data corruption. With this, you will be.
Wait, how would this be any more vulnerable to system-level data corruption than a normal update? The worst case I can see is that you have a properly updated tuple but the new tuple version is indexed incorrectly just as would be the case if you have a functional index or expression index which had changed value since the update was performed. I agree about the costs for evaluating the expressions. But a COLD update is certainly going to have to evaluate both expressions once. The only additional cost here is that HOT is going to have to evaluate the *old* expression as well. So it's at worst twice as expensive as a normal COLD update. I think I'm leaning towards doing a binary comparison of the parameters to the expressions. That won't catch as many cases as comparing the results of the expressions -- and I can think of cases where that would be disappointing -- but it's in keeping with how it determines whether a tuple is eligible for a HOT update in the first place. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
