"Tom Lane" <tgl@sss.pgh.pa.us> 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
