> On 24 Feb 2020, at 10:58, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> > wrote: > > This is a change to make the bitmap of updated columns available to a trigger > in TriggerData. This is the same idea as was recently done to generated > columns [0]: Generic triggers such as tsvector_update_trigger can use this > information to skip work if the columns they are interested in haven't > changed. With the generated columns change, perhaps this isn't so > interesting anymore, but I suspect a lot of existing installations still use > tsvector_update_trigger. In any case, since I had already written the code, > I figured I post it here. Perhaps there are other use cases.
I wouldn't at all be surprised if there are usecases for this in the wild, and given the very minor impact I absolutely think it's worth doing. The patches both apply, compile and pass tests without warnings. The 0001 refactoring patch seems a clear win to me. In the 0002 patch: + For <literal>UPDATE</literal> triggers, a bitmap set indicating the + columns that were updated by the triggering command. Generic trigger Is it worth pointing out that tg_updatedcols will be NULL rather than an empty Bitmapset for non-UPDATE triggers? bitmapset.c treats NULL as an empty bitmap but since a Bitmapset can be allocated but empty, maybe it's worth being explicit to help developers? There isn't really a test suite that excercises this IIUC, how about adding something like the attached diff to contrib/lo? It seemed like a lower impact change than widening test_tsvector. +1 on the patchset, marking this entry as Ready For Committer. cheers ./daniel
lo_trig_test.diff
Description: Binary data
