Mats Lofkvist <mal@algonet.se> writes:
> tgl@sss.pgh.pa.us (Tom Lane) writes:
>>> (In my case, I think the call to _bt_check_unique could be
>>> avoided altogether since the update isn't changing any of
>>> the columns present in the unique key.
>>
>> It's fairly difficult for the index AM to know that; in general we don't
>> have access to the old tuple to check, at the time the index update is
>> running.
> But you really shouldn't need the old tuple to know this since none
> of the columns present in the unique index are 'set' by the update?
> I.e. the 'not changing the unique key part' is not data dependent,
> it is guarantied by the form of the update statement.
(a) that's even further upstream from the index AM, and (b) what about
BEFORE triggers that change the tuple contents?
regards, tom lane