Logical replication - proposal for a custom conflict resolution function

Hello hackers, I'd like some feedback on a logical replication feature I
would like to write a patch for.
The feature would allow users to register a custom conflict handler
function to be executed for each conflicting row, after the built-in
conflict resolver has run.

Running after the built-in conflict resolver allows the function to use the
value provided by the resolver, for instance for custom logging.

The proposed programming model for the function follows the model for
trigger functions - a set of read only variables are populated in the
top-level block, and the function returns a record or NULL.

The conflict handler function would have more variables. At minimum, three
records - the local version of the new value, the remote version of the new
value, the value returned by the built-in resolver function - rather than
the two for a trigger function, the timestamp information for the local and
remote updates, the conflict type detected and the resolver used.

The new syntax proposed may look something like this:
CREATE SUBSCRIPTION <subname>
CONNECTION <conninfo>
PUBLICATION <pubname>
CONFLICT RESOLVER (conflict_type1 = resolver1 [, conflict_typeN =
resolverN,... ])
[conflict_handler=my_custom_function]) // <--- allow users to pass a
custom conflict resolution function.

Please let me know your thoughts, thanks!

Diego