Re: The suppress_redundant_updates_trigger() works incorrectly

Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>> Tom Lane wrote:
>>>
>>>> ... however, it seems reasonable to assume that the *new* tuple is just
>>>> local storage. Why don't you just poke the old tuple's OID into the
>>>> new
>>>> one before comparing?
>>>>
>>
>>
>>> OK, that will be easy enough. I assume I should still put InvalidOid
>>> back again afterwards, in case someone downstream relies on it.
>>>
>>
>> Can't imagine what ...
>>
>>
>>
>
> OK, left off - anything for speed.
>
> fix committed.

FYI, the reason why I noticed the behavior is SE-PostgreSQL also stores its
security attribute at the padding field of HeapTupleHeaderData, as "oid" doing.

Your fix can be also applied to preserve security attribute, however,
I reconsidered it is more preferable to separate its memcmp() into two
phases, the one is data fields, the other is system attributes, because
a fact of the field with InvalidOid shows the given query does not touch
the future writable system attribute, and it helps security modules to
check easiler whether the security attribute is tried to update, or not.

How do you think my approach within the attached patch?

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>