Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding

Hi Ajin,

Here is another general review comment for patch 0001.

~~~

I keep getting confused by the distinction between the 2 member fields
that are often found working hand-in-hand:
entry->filterable
rb->can_filter_change

Unfortunately, because the names are very similar I keep blurring the
meanings, and then nothing makes sense.

IIUC, the meanings are actually like:

entry->filterable. This means filtering is *possible* for this kind of
relation; it doesn't mean it will happen though.

rb->can_filter_change. This means the plugin will *try* to filter the
change; it might do nothing if entry->filterable is false;
can_filter_change bool is used for the 100 change "temporary
suspension" logic (e.g. so it if is false we won't even try to filter
despite entry->filterable is true).

If those meanings are accurate I think some better member names might be:
entry->filterable
rb->try_to_filter_change

Also these explanations/distinctions need to be made more clearly in
the commit message and/of file head comments, as well as where those
members are defined.

======
Kind Regards,
Peter Smith.
Fujitsu Australia.